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Abstract 

A  discipllna  tor  loop  construction  Is  prasontad  which  li. 
basad  on  tha  concapt  of  a  watt-formad  postcondition.  A 
wall-tormad  postcondition  Is  saan  to  hava  an  implicit  logi¬ 
cal  structura  which  la  mada  axpUcit  by  appropriata  varlabla 
binding.  This  varlabla  binding  Idantiflaa  tha  loop  invariant 
and  a  datarminata.  Loops  ara  than  constructad  by  first 
idantifying  tha  waakaat  Itarativa  machanlsm  capable  of 
astabllahlng  tha  postcondUion.  Subsaquant  davalopmant 
procaads  by  way  of  inductive  stepwise  rafinamant.  This 
discipline  for  loop  construction  leads  naturally  to  a  schema 
for  classifying  loop  mechanisms.  It  also  leads  to  a  propo¬ 
sal  tor  a  waaM  loop  grammar  (not  in  principle  unlike 
Chomsky's  phrase  structura  grammar)  which  helps  to 
make  explicit  semantically  important  components  of  a  loop 
structura.  Tha  grammar  la  enhanced  by  a  sat  of  funda¬ 
mental  transformation  rules. 
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ABSTRACT 


A  discipline  for  loop  construction  is  presented  which  is  based  on 
the  concept  of  a  well-formed  postcondition.  A  well-formed  postcondition 
is  seen  to  have  an  implicit  logical  structure  which  is  made  explicit  by 
appropriate  variable  binding.  This  variable  binding  identifies  the  loop 
invariant  and  a  determinate.  Loops  are  then  constructed  by  first  identify¬ 
ing  the  weaKest  iterative  mechanism  capable  of  establishing  the 
postcondition.  Subsequent  development  proceeds  by  way  of  inductive 
stepwise  refinement.  This  discipline  for  loop  construction  leads  naturally 
to  a  scheme  for  classifying  loop  mechanisms,  it  also  leads  to  a  proposal 
for  a  weak  loop  grammar  (not  in  principle  unlike  Chomsky's  phrase 
structure  grammar)  which  helps  to  make  explicit  semantically  important 
components  of  a  loop  structure.  The  grcmmar  is  enhanced  by  a  set  of 
fundamental  transformation  rules. 
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1.  Introduction 

‘Everything  should  be  made  as  simple  as  possible,  but  not  simpler* 


Einstein 

Loops  play  a  central  role  in  programming  and  therefore  deserve  a  sound  metho¬ 
dology  to  support  their  development  and  application.  The  work  of  Floyd  on  assertions  I 
1  ].  Hoare  on  loop  invariants  [  2 ).  and  Oijkstra's  weakest  precondition  methodology  [  3 
]  has  gone  a  long  way  towards  formalizing  certain  aspects  of  the  construction  and 
Characterization  of  loops.  Despite  this  formalization,  and  the  positive  contribution  of 
structured  programming  to  loop  construction  it  is  apparent  that  there  are  still  some 
aspects  of  the  methodology  that  require  further  clarification  and  development 

We  suggest  that  existing  methodology  and  practice  does  not  always  provide  ade¬ 
quate  guidance  on  the  most  appropriate  initialization  for  a  loop,  on  what  constitutes  a 
suitable  guard  for  a  loop,  on  how  the  loop  invariant  can  be  determined,  and  on  where 
various  constructs  should  be  arranged  in  the  body  of  a  loop,  imprecision  with  any  of 
these  details  can  often  result  In  poorly  constructed  loops,  in  the  discussion  which  fol¬ 
lows  we  will  attempt  to  address  and  clarify  a  number  of  these  issues. 

Dijkstra  s  methodology  [  3  ]  provides  a  useful  reference  point  from  which  to  view 
our  alternative  proposal.  We  will  therefore  begin  our  discussion  by  briefly  reviewing 
his  method. 

The  starting  point  with  Dijkstra's  method  is  a  formal  specification  of  the  problem. 
This  specification  must  yield  an  associated  postcondition  R  which  precisely  defines  the 
goal  to  be  accomplished,  if  it  is  then  recognized  that  the  problem  requires  a  loop  (or 
loops)  the  next  step  is  to  determine  an  appropriate  loop  invariant  P  by  weakening  (or 
generalizing)  the  predicate  R  in  some  way.  Useful  heuristics  which  have  been  sug¬ 
gested  for  this  purpose  include,  replacing  a  (X)nstant  by  a  variable  in  R.  deleting  a 
conjunct  from  R.  and  adding  a  disjunct  to  R.  An  initialization  process  is  then  per¬ 
formed  to  establish  the  truth  of  the  invariant  P  before  the  loop  is  entered.  The  guard  B 
for  the  loop  is  then  developed  so  that  P  ->  R.  Finally,  the  body  of  the  loop  is 
developed  in  such  a  way  that  it  will  decrease  a  bound  function  associated  with  the  loop 
with  each  iteration  while  re-establishing  the  truth  of  the  invariant.  Detailed  accounts 
and  applications  of  this  methodology  are  given  in  monographs  by  Dijkstra  t  3  J  and 
ones  ( 4  J. 

At  this  point  we  have  not  considered  altemabve  programming  disciplines  as  sug¬ 
gested  by  Jackson  (  5  ]  and  Warnier  (  6  1.  Later  in  the  discussion  some  of  the  issues 
raised  by  Jackson's  method  in  particular  will  be  taken  into  account.  With  the  back¬ 
ground  we  have  outlined  we  can  now  consider  an  alternative  strategy  for  loop 


J 


construction.  In  presenting  our  proposals  we  have  deliberately  chosen  to  keep  the 
treatment  relatively  informal  to  minimise  distraction  from  clearly  presenting  how  the 
method  can  be  applied  in  practice  in  a  straightforward  manner. 

In  presenting  his  methodology  Oijkstra  suggests  a  number  of  ways  of  weakening 
the  postcondition  R  to  obtain  the  invariant  P.  However  in  practice  the  problem  of 
determining  an  appropriate  loop  invariant  prior  to  constructing  a  loop  often  requires 
considerably  more  invention,  insight,  and  experience,  than  is  perhaps  desirable. 

We  would  suggest  that  the  problem  of  determining  an  appropriate  loop  invariant 
can  be  eased  by  taking  a  somewhat  different  approach. 

2.  A  Loop  Calculus 

A  starting  point  for  the  discussion  of  an  alternative  methodology  is  to  take  a 
somewhat  different  view  of  the  postcondition  R  to  that  conventionally  used.  There  is 
Clearly  more  than  one  way  in  which  we  can  express  a  postcondition  R  for  a  particular 
problem.  Furthermore  some  expressions  R  are  more  useful  than  others  in  conveying 
information  that  may  be  helpful  in  constructing  the  loop  to  establish  the  goal  sought, 
in  this  respect  the  suggestion  made  by  Oijkstra  is  to  formulate  a  postcondition  that  will 
permit  generalization  (or  weakening)  in  moving  back  further  from  the  end-result  We 
would  suggest  that  the  process  of  characterizing  useful  postconditions  can  be  taken  a 
step  further  by  requiring  that  the  postconditions  R  always  assume  a  specific  logical 
structure.  This  structure  requires  that  the  postcondition  R  for  a  loop  be  thought  of  as 
the  conjunction  of  an  invariant  P  and  a  determinate  O.  i.e. 

R  =  P  A  D 

A  postcondition  R  with  this  structure  is  said  to  be  well-formed.  We  will  see  a  iittie 
later  how  the  logical  elements  P  and  0  are  projected  from  well-formed  postconditions 
R.  The  invariant  P  is  that  predicate  component  of  R  which  is  true  before  and  after 
each  loop  iteration.  The  truth  of  the  determinate  0  for  some  specific  value  or  values  of 
variables  associated  with  R  determines  the  truth  of  the  postcondition  R. 

The  role  of  the  loop  body  when  we  have  a  well-formed  postcondition  is  to  estab¬ 
lish  the  truth  of  the  determinate  while  maintaining  the  truth  of  the  invariant  P.  With  the 
determinate  O  true  the  postcondition  R  is  established.  Progress  towards  establishing 
me  truth  of  the  determinate  can  be  measured  by  associating  with  a  loop  a  bound  func¬ 
tion  t  that  remains  greater  than  or  equal  to  zero  and  which  is  monotonically  decreas¬ 
ing  wim  successive  iterations  of  the  loop. 

The  job  of  the  guard  B  of  the  loop  is  to  terminate  the  loop  either  when  the  deter¬ 
minate  is  true  or  when  a  state  has  been  reached  where  it  is  possible  to  establish  the 
truth  of  the  determinate  by  some  mechanism  associated  with,  but  external  to  the  loop. 

2.1.  Projection  of  the  Invariant  and  Determinate  from  the  Postcondition 

To  do  this  we  must  examine  the  underlying  nature  of  the  postcondition  R. 
Postconditions  are  expressed  m  terms  of  variables  and  constants.  The  constants 
represent  the  input  or  given  information  about  the  problem.  The  role  of  the  loop  or 
program  that  must  be  derived  is  to  perform  operations  on  the  variables  and  me  given 
data  until  a  state  is  attained  which  satisfies  the  postcondition. 

initially  when  the  postcondition  is  derived  the  free  variables  associated  wim  the 
problem  have  not  been  initialized  or  bound  to  specific  values  although  they  may  have 
attached  ranges  which  define  me  set  of  possible  values  mat  they  may  assume. 

With  our  proposed  method  for  determining  the  loop  invariant  a  first  step  is  to 
Identify  me  free  variables  in  me  postcondition.  The  next  step  is  to  attach  valid  ranges 
to  each  of  these  variables  (as  noted  before,  some  may  already  have  ranges  attached 


in  the  postcondition),  in  some  instances  it  is  possible  to  establish  both  a  lower  and  an 
upper  bound  for  a  variable  while  in  other  cases  it  may  only  be  possible  to  establish 
either  a  lower  or  an  upper  bound  or  some  defined  value,  in  such  cases  the  undefined 
bound  can  only  be  expressed  symbolically  and  is  therefore  not  of  any  direct  use  in  the 
steps  to  follow,  in  general  the  bounds  for  variables  can  be  derived  from  a  knowledge 
of  the  given  information  associated  with  the  problem.  Once  ranges  nave  been  esta¬ 
blished  for  all  variables  the  next  step  is  to  use  this  information  to  protect  the  invariant 
P  out  of  the  postcondition  R.  Projection  of  the  invariant  from  the  postcondition  is 
achieved  by  binding  all  the  variables  in  the  postcondition  to  one  of  their 
defined  bounds  or  limiting  values.  When  this  has  been  done  those  components  of  the 
postcondition  that  are  established  by  the  variable  binding  to  be  logically  true  for  all 
valid  states  defined  by  the  postcondition  are  said  to  constitute  the  projected  invariant  P 
for  the  associated  postcondition  R.  These  values  of  the  variables  referred  to  as  their 
protection  values  can  obviously  be  used  for  the  initialization  of  the  loop  that  still  needs 
to  be  derived. 

in  essence  we  have  reversed  the  order  of  the  sequence  of  steps  suggested  by 
Oijkstra  (  3  ].  Rather  than  first  determining  the  invariant  P,  and  then  assigning  values 
to  variables  to  establish  it  to  be  true  initiaiiy  before  the  loop  is  entered,  we  take  the 
steps  in  reverse  order.  That  is.  valid  bounds  are  assigned  to  variables  and  then  these 
variable  bindings  are  used  to  identify  the  invariant  logical  elements  in  the  postcondi¬ 
tion.  This  achieves  the  same  end  result  as  Oijkstra' s  method  -  an  invariant,  and  an 
appropriate  initialization  to  establish  the  initial  truth  of  the  invariant  before  loop  entry. 
However,  there  is  usually  a  lot  less  invention  required  to  establish  ranges  for  variables 
Which  in  any  case  should  be  already  available  if  the  postcondition  is  well-formed. 

Those  logical  components  of  the  postcondition  that  are  not  established  by  the 
variable  binding  to  belong  to  the  invariant  are  identified  as  belonging  to  the  deter¬ 
minate.  They  are  true  tor  specific  values  of  variables  and  constants  associated  with 
the  problem.  The  truth  of  the  determinate,  however,  determines  the  truth  of  the 
postcondition  for  some  specific  configuration  of  the  state  variables.  There  are  two 
states  where  the  determinate  is  true,  a  non-iterative  state  corresponding  to  the  smal¬ 
lest  problem  that  the  mechanism  can  solw  and  the  more  general  state  that  applies  at 
the  termination  of  the  iterative  process.  It  is  important  to  analyse  both  of  these  states. 
Choosing  values  of  the  given  data  that  establish  the  truth  of  the  determinate  (assuming 
variable  binding  has  been  previously  applied)  without  iteration  allows  us  to  determine 
What  we  shall  call  the  postcondition  guard  Bq  of  the  loop.  This  data  sizing  defines  tne 
dimensions  of  the  smallest  valid  problem  tor  which  the  postcohdition  can  be  esta¬ 
blished  to  be  true.  Accordingly,  a  corresponding  guard  must  be  applied  to  protect  tne 
mechanism  from  data  for  which  the  postcondition  is  not  defined. 

The  more  general  state  in  which  the  determinate  is  true  can  only  apply  after  an 
iterative  process  has  terminated.  Having  identified  the  invariant  and  the  determinate 
the  next  step  is  to  determine  the  structure  of  the  loop  body. 

2.2.  Construction  of  the  Loop  Body 

The  role  of  the  loop  body  is  clearly  to  take  the  state  of  the  computation  from  that 
of  initialization  to  a  state  where  the  postcondition  is  satisfied.  The  suggestion  for 
developing  the  loop  body  made  by  Qries  [  4  ]  is  to  construct  it  so  that  it  decreases  me 
bound  function  while  re-establishing  the  loop  invariant.  While  this  is  sound  advice  it 
would  be  useful  to  provide  more  detailed  and  more  specific  advice  on  such  issues  as 
What  structure  the  loop  body  should  take,  what  components  should  make  up  that  loop 
body,  and  now  they  can  be  constructed. 

The  business  of  problem-solving  can  invariably  be  made  easier  if  ft  is  possible  to 
break  a  problem  down  into  a  number  of  sub-problems  that  can  be  considered  one  at  a 
time,  in  the  present  context  we  are  looking  for  a  systematic  procedure  that  will  break 


tne  problem  of  developing  the  loop  body  into  a  set  of  well-defined  and  more  manage¬ 
able  sub-problems.  At  the  same  time,  what  should  always  be  an  important  considera¬ 
tion  in  computing  is  the  development  of  efficient  solutions  to  problems. 

In  our  search  for  such  a  systematic  procedure  we  must  pay  more  detailed  atten¬ 
tion  to  the  nature  and  structure  of  the  postcondition.  With  many  problems  that  require 
iterative  solution  there  is  often  a  whole  spectrum  of  given  initial  data  configurations 
that  must  be  taken  through  to  the  postcondition.  Furthermore,  some  initial  configura¬ 
tions  should  require  considerably  less  effort  than  others  to  establish  the  postcondition 
te.g.  we  may  have  a  set  of  data  to  be  sorted  in  which  only  a  very  small  fraction  of  tne 
eiements  are  out  of  order).  We  may  ask  at  this  stage  what  is  the  use  of  investigating 
such  specialized  initial  configurations  for  the  given  data?  As  it  turns  out  consideration 
of  such  limiting  special  cases  is  often  very  useful  in  constructing  mechanisms  to  solve 
general  problems.  As  a  starting  point  for  constructing  the  loop  body  it  is  useful  to 
consider  first  valid  configurations  of  the  given  data  that  should  require  tne  least  effort 
to  establish  the  postcondition.  The  corresponding  weakest  iterative  mechanism  capa¬ 
ble  of  establishing  the  postcondition  under  such  conditions  will  be  referred  to  as  tne 
rr-mechamsm  associated  with  the  loop. 

The  nature  of  the  Tl-mecnanism  and  the  role  that  it  can  play  in  the  solution  of  a 
problem  of  course  can  vary  considerably  from  problem  to  problem.  There  are.  how¬ 
ever.  a  number  of  important  classes  of  TT-mechanism  that  are  easy  to  recognize  and 
apply. 

As  the  n-mechanism  alone  is  usually  not  capable  of  establishing  the  postcondi¬ 
tion  directly  for  more  general  initial  states  (e.g.  it  may  be  required  to  sort  random  data) 
it  must  frequently  be  accompanied  by  some  other  called  tine  /rmechan ism.  The  roie  of 
tne  ^-mechanism,  at  each  application,  is  to  change  the  state  of  the  computation  into 
a  configuration  where  the  iT-mechanism  can  again  be  applied,  in  some  cases  this 
involved  a  straightforward  initialization  while  in  other  instances  deductive  steps  must 
be  applied. 

It  IS  important  to  understand  the  relationship  of  the  n-mechanism  with  the 
postcondition,  in  essence  the  n-mechanism  corresponds  to  that  mechanism  which 
Changes  the  least  number  of  variables  associated  with  the  postcondition  but  still  allows  It 
to  decrease  the  bound  function  and  hence  make  progress  towards  establishing  the 
postcondition.  Whenever  the  IT-mechanism  reaches  a  state  where  other  variables 
must  be  changed  to  make  further  progress,  the  n-mechanism  terminates  and  the  A- 
mecnanism  must  be  applied. 

We  wiil  return  to  the  application  of  these  ideas  after  we  have  discussed  how  loop 
guards  can  be  derived. 

2.3.  Oerivation  of  the  Loop  Guard 

To  derive  the  guard  for  a  loop  characteristics  of  the  loop  body  must  be  related  to 
the  bound  function  in  order  to  derive  the  most  appropriate  guard. 

The  characteristics  of  the  loop  body  which  we  must  take  into  account  in  deriving 
loop  guards  can  be  embodied  in  what  we  shaii  cali  the  iterative  capacity  41  of  the  loop. 
The  maximum  iterative  capacity  of  a  loop,  is  the  maximum  amount  by  which  the 
elements  of  the  loop  body  can  decrease  the  bound  function  associated  with  the  loop  in  a 
Single  iteration  tor  the  smallest  general  problem  that  requires  iterative  solution.  Many 
loops  have  a  maximum  iterative  capacity  41^-^  of  1.  in  which  case  the  whole  process 
of  deriving  the  guard  is  straightforward,  in  instances  where  the  iterative  capacity  is 
greater  than  one  considerable  care  should  be  taken  in  choosing  the  guard  for  me 
loop. 

A  rule  that  can  be  widely  applied  in  deriving  the  guard  for  the  loop  is  to  simply  set 
up  a  relationship  such  that  the  bound  function  t  for  the  loop  is  greater  than  or  equal  to 


the  maximum  iterative  capacity  of  the  loop  i.e. 

*  - 

The  bound  function  can  usually  be  derived  directly  from  the  invariant  or  determinate  if 
the  postcondition  is  well-formed,  in  special  cases  where  a  loop  contains  only  outer 
loops  a  different  strategy  for  determining  the  loop  guard  must  be  used.  These  issues 
wilt  be  discussed  later. 

There  is  an  important  difference  between  the  present  approach  to  determining 
the  loop  guard  and  that  of  Oljkstra  (  3  1  where  the  guard  is  derived  before  rather  than 
after  the  body  of  the  loop  has  been  determined.  Incorporating  information  about  the 
body  of  the  loop  in  deriving  the  guard  avoids  the  problem  of  /oop  overdesign.  Loop 
overdesign  occurs  when  a  loop  is  allowed  to  do  more  iterations  than  are  sufficient  to 
solve  the  problem.  When  a  guard  allows  this  condition  it  is  often  necessary  to  employ 
additional  guards  within  the  loop  to  ensure  maintenance  of  the  invariant.  We  will  come 
back  to  the  problem  of  loop  overdesign  later.  When  specific  problems  which  exhibit 
this  characteristic  are  considered,  we  can  see  how  the  methodology  we  have  outlined 
can  be  applied  in  practice. 

3.  Some  Small  Examples 

In  this  section  we  will  illustrate  how  the  methodology  we  nave  outlined  can  oe 
applied  to  some  well-known  problems.  In  the  first  several  examples  the  weakest  itera¬ 
tive  mechanism  solves  the  problem  for  all  cases  and  consequently  does  not  require 
generalization. 

Example  3.1  Integer  Square  Root  Approximation 

Given  an  integer  n  stabiish  the  largest  integer  *a‘  that  is  less  than  or  equal  to  ?n.  The 
postcondition  for  this  problem  can  be  written  as: 

R;  •  i  n  <  (a+1)^ 

It  IS  convenient  to  rewrite  it  as  a  set  of  con|unctions.  i.e. 

R:  e  1  a^  ‘  a^  i  n  *  n  <  (a+1)^ 

The  only  variable  in  the  postcondition  is  *a*.  The  range  for  this  variable  r.  is: 

Q 

Tg;  e  ^  a  ^  n. 

Possible  protection  values  are  a  =  0.  and  a  =  n.  Choosing  e  as  the  projection  value  for 
*a’  and  substituting  it  into  the  postcondition  yields: 

e  sa^  ~>  true 

2 

a  sn  =>  true 

n<ia+l)^  =>  true  for  no  =  e.  false  for  n  >  e 

Remembering  that  the  invariant  P  is  that  part  of  R  established  to  be  true  by  variable 
binding  using  the  projection  values  we  get  as  the  projected  invariant 

P:  esa^  ‘  a^  so 

The  remaining  part  of  R  constitutes  the  determinate  O  tor  the  problem.  We  have 
D:  n  < ia+1)^ 

A  suitable  bound  function  for  the  problem  can  be  derived  from  the  invariant,  in  mis 
case  we  nave  n  >.  avu2\d  and  hence  we  can  use 
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n-sr  i  d 


The  task  at  hand  now  is  to  construct  a  loop  that  will  establish  the  truth  of  the  deter¬ 
minate  While  maintaining  the  truth  of  the  invariant.  Once  the  determinate  is  true  tne 
postcondition  will  be  established.  We  can  attempt  to  make  progress  towards  estab¬ 
lishing  0  by  increasing  ‘a*  under  the  invariance  of  P.  The  loop  body  can  therefore 
consist  of  the  assignment  a  ;=  a->-1  which  must  be  applied  in  this  case  until  the  deter¬ 
minate  is  true  (i.e.  until  n  <  (a-<-1)\u2\d).  However,  for  consistency,  rather  than  applying 
tne  complement  of  the  determinate  directly,  we  will  use  the  ideas  described  in  the  last 
section  for  deriving  guards.  We  nave 

t;  n  -  a^  2.  e  (from  invariant) 

*^max'  ^  ^ 

B:  t  >  (if 
“  ~  ^max 

o 

6;  n  -  a  >.  2a+l  on  substitution 
B:  n  >.  (a+1)^  =  (a+1)^  ±  n 

Notice  that  we  have  arrived  at  the  same  guard  as  by  simply  complementing  the  deter¬ 
minate  in  this  simple  case.  Our  implementation  therefore  has  the  form: 

do  (a+1)^  i  n  — >  a:=  a+i  od 

It  IS  interesting  as  an  exercise  to  use  the  other  possible  projection  value  for  ‘a*  (i.e.  a 
=  n).  Substituting  this  value  for  ‘a*  into  the  postcondition  R  yields; 

®  i  a^  =>  true 
n  <  ta+1)^  =>  true 

a  ^  n  =>  true  for  n  i.  1 ,  false  otherwise 

The  projected  invariant  P  is  in  this  case  is  therefore 
P;  •  i  a^  A  n  <  (a+1)^ 

The  determinate  O  is 
D;  a^  1  n 

Following  similar  arguments  to  those  used  for  the  first  solution,  we  get: 
do  a^  >  n  — >  a:=  a- 1  od. 


Example  3.2  Quotient  Remainder  Problem 

Given  integers  x  and  d.  establish  the  quotient  q.  and  remainder  r,  resulting  from 
division  of  X  by  d  without  using  the  division  operator.  Stated  more  formally,  we  can 
express  tne  postcondition  R  as 

R:  tx  *  q  *  d  +  r)  A  (®  ^  r  <  d) 
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Also  given  is  that  x  >.  e  and  d  >  a.  The  postcondition  can  be  rewritten  as: 

R;  tx  =  q*d  +  r)''6i.rAr<d 

The  free  variables  associated  with  the  postcondition  are  r  and  q.  The  ranges  for  tnese 
two  variables  are: 

q;  le  1  q  ^  X)  note  r  =  a  and  d  =  1  gives  q  =  x 
r:  (a  jL  f  i. 

There  are  four  possible  combinations  of  projection  values  for  the  two  variables. 
Choosing  r  =  x  and  q  =  a  as  the  projection  values  avoids  any  special  compensation  for 
0.  Substituting  these  values  for  r  and  q  into  the  postcondition  R  yields: 

x  =  q“d  +  r  =>  true 
OS  r  =>  true 

r  <  0  =>  true  for  x  <  d,  false  for  x  >.  o. 

The  projected  invariant  P  is  in  this  case  therefore: 

P:  tx  =  q  *  d  +  r)  A  (4(  ^  r> 

The  determinate  0  is 

D:  r  <d 

The  determinate  will  be  true  directly  provided  x  is  initially  less  than  0.  However,  me 
problem  statement  does  not  say  anything  about  the  relationship  between  the  magni¬ 
tude  of  X  and  of  d  and  so  our  algorithm  must  be  able  to  accommodate  x  >.  d. 

Examining  the  invariant  P  we  see  that  a  suitable  bound  function  follows  directly  from 
me  conjunct  te  s  r).  That  is  we  can  use 

t:  r  i  0 

The  tasK  that  remains  is  to  construct  a  mechanism  mat  will  establish  the  truth  of  me 
determinate  0  while  maintaining  the  truth  of  the  invariant  P.  Because  division  is  not 
allowed  (from  the  problem  definition)  an  iterative  process  is  needed.  The  projection 
values  for  r  and  q  can  be  used  to  initialize  the  variables  associated  with  the  loop.  The 
roie  of  the  loop  body  mat  we  must  construct  in  this  instance  is  to  establish  the  truth  of 
determinate  by  decreasing  the  bound  function  while  keeping  P  true.  This  will  involve 
decreasing  r.  Reference  to  the  invariant  indicates  tnat  the  only  way  to  keep  it  true 
while  decreasing  r.  is  to  reduce  r  by  multiples  of  d.  For  each  change  in  r  by  a  multiple 
of  d  mere  will  need  to  be  an  integral  change  in  q  to  keep  P  true  after  each  iteration. 
As  our  tentative  loop  structure  we  have  at  this  stage: 

r  :=  X.  q  o: 

00  ?  — > 

r  :=  r  -  0.  q  :=  q  +  1 

00 
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Our  next  task  is  to  derive  a  suitable  guard  for  the  loop.  Examining  the  loop  body  we 
see  that  the  maximum  iterative  capacity  =  d.  We  therefore  have: 

t:  r  >.  e 

Umax:  d 


We  can  now  write  down  the  full  details  of  the  algorithm.  For  the  implementation  of  the 
various  algorithms  that  will  be  presented  we  have  used  essentially  Oijkstra's  mini¬ 
language  [  3  ]  with  some  extensions  and  variations  that  we  have  felt  appropriate.  Any 
deviations  from  Oijkstra's  language  will  be  Identified  as  they  are  encountered. 

The  quotient  remainder  implementation  is  as  given  below: 

Ip  0 1 X  *  e  <  d  — > 

$vr  r,q  :  integer  — > 
r  :*  X,  q  :=  0; 

$do  r  >.  d  — > 

r  :=  r-d.  q  :=  q+1 

$od: 

$r:  r  <  d  =>  r,  q 
P' 

Some  comments  on  the  conventions  used  in  this  implementation  are  in  order.  The 
construct: 


ip  Bp  — > 

P‘ 

parenthesizes  a  mechanism  whose  role  is  to  establish  a  defined  postcondition  R.  it  is 
not  an  iterative  construct,  it  is  like  an  if-construct  but  is  more  powerful  because  of  its 
information  hiding  capability.  The  postcondition  guard  Bp  will  only  allow  entry  to  the 
mechanism  when  it  is  true  (i.e.  in  this  case  d  i.x  ^  0  <  d  must  be  true). 

By  convention  the  only  variables  returned  from  the  Ip  ...  pi  construct  are  those  speci¬ 
fied  in  the  $r:  state.  Variables  specified  In  $r:  state  will  only  be  bound  and  returned  to 
the  external  environment  when  the  determinate  guard  is  true.  In  general  we  have 

$r:  Bq  =>  <  variable  list  to  be  returned  > 

In  the  example  Bp  takes  the  form  r  <  d.  Should  the  mechanism  terminate  in  a  state 
Where  the  determinate  guard  is  not  true  then  the  variables  listed  to  be  returned  to  the 
external  environment  will  remain  unbound.  This  condition  can  be  used  to  signal  a 
situation  where  it  definitely  cannot  be  inferred  that  the  mechanism  has  established  the 
defined  postcondition.  The  same  situation  will  apply  in  cases  where  the  postcondition 
guard  Bp  is  initially  false. 

All  variables  internal  to  the  mechanism  are  defined  internally  in  the  $vr  state.  The 
conventions  used  for  Pascal  for  definition  and  typing  are  employed.  The  iterative 
states  of  the  mechanism  used  to  establish  the  major  postcondition  are  parenthesised 
by  a  $do  ..  $od  construct.  Minor  loops  included  within  the  mechanism  use  the  con¬ 
ventional  do  ..  od  notation.  Where  there  is  no  preference  for  order  of  execution  of  a 
group  of  statements  these  statements  are  separated  by  commas  rather  than  semi¬ 
colons  provided  there  is  no  evaluation  contention.  (For  example,  the  two  statements  r 
;=  r-o  and  q  :=  q+1  can  be  safely  executed  concurrently.)  Where  there  is  a  possibility 
of  contention  the  concurrent  assignment  operator  used  by  Dijkstra  [  3  ]  is  adopted. 

Concurrency  is  used  throughout  the  paper  as  a  tool  to  ensure  that  the  invariant  is 
maintained  at  all  times  rather  than  lust  Initially,  and  after  each  iteration  of  a  loop.  We 
consider  this  requirement  to  be  a  central  principle  of  good  loop  design.  Applicative 
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consiaer  tins  requirement  to  be  a  central  principle  ot  gooa  loop  oesign.  Applicative 
languages  provide  an  alternative  means  for  meetng  this  requirement. 

Other  aspects  of  this  variant  of  Oijkstra's  mini-language  will  oe  oeflneo  as  they 
are  encountered  in  later  problems. 

Example  3.3  A  Symmetric  Binary  Search 

The  binary  search  of  an  ordered  array  is  one  of  the  most  widely  cited  examples  in 
introductory  computing  science  texts.  Unfortunately  solutions  to  the  problem  are 
rarely  well  formulated  and  well  presented.  We  therefore  felt  at  liberty  to  offer  yet 
another  somewhat  different  solution  which  hopefully  stands  up  a  little  better  to  some  ot 
me  criticisms  we  have  hinted  at. 

The  key  to  developing  a  ‘good*  implementation  for  the  binary  search  is  in  the  for¬ 
mulation  of  a  welt  formed  postcondition  in  the  first  instance.  Before  we  can  do  this  we 
need  a  clear  statement  of  the  goal  we  are  seeking.  We  are  given  an  ordered  array 
a(1..nei  and  a  search  value  x  and  are  required  to  establish  whether  or  not  a  value 
equal  to  x  is  present  in  the  array.  Our  mechanism  should  return  a  boolean  variable 
found  handle  all  cases  including  an  empty  array.  It  is  possible  that  elements  in  me 
array  are  not  unique  and  x  may  be  less  than  the  first  element  or  greater  man  the  last 
element  in  the  array.  Given  these  requirements  we  want  a  mechanism  that  maintains 
a  suitable  invariant  throughout. 

The  most  natural  requirements  on  how  the  mechanism  should  terminate  are  as 
follows.  If  X  Is  absent  from  the  array  our  mechanism  should  terminate  having  effec¬ 
tively  accounted  for  all  possible  locations  in  the  array.  In  this  case  we  should  be  able 
to  establish  limits  i,  and  n  defining  two  array  elements  between  which  the  value  sought 
X,  lies  (apart  from  the  two  limiting  cases).  We  might  represent  this  schematically  as 
follows: 


n 


>  X 


<  X 


found  =  false 
i  =  n-1 
a(i]  <  X  <  a(n] 


In  the  other  case  where  x  is  present  we  again  want  to  account  for  ail  elements  m  me 
array.  The  limits  in  this  Instance  can  most  appropriately  point  to  the  array  location 
where  the  value  equal  to  x  is  located.  Our  algorithm,  in  this  case,  could  terminate  as 
our  schematic  diagram  below  indicates,  i.e. 


I,  n 


found  =  true 
I  =  n 

a(i]  =  X  =  a(nl 


Taking  into  account  the  requirements  for  termination  and  using  Oijkstra's  advice  about 
trying  to  formulate  a  postcondition  that  will  permit  generalization  or  weakening  to  an 
earlier  state  further  from  the  end  result,  we  are  led  to  the  following  postcondition: 


R:  id  SI  S  nd)  A  Vp  ((1  ^  p  jc  I)  =>  (alpj  s  x)) 

^  (1  i,  n  i.  no+l)  A  Vq  ((n  1  q  nO)  =>  (a[q]  >.  x)) 

A  ((i  =  n  A  X  *  a[l}  A  found)  V  (i+1  =  n  A  7found» 

The  free  variables  associated  with  the  postcondition  are  i,  n  and  found.  Their  ranges 
are: 


UliA 


♦j 
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i:  (6  ^  i  ^  nd) 

n:  (1  n  1  nd+l 

found:  (false,  true) 

We  can  cnoose  i  =  o.  n  ;=  ne+1  and  found  =  false  as  the  projection  values.  Substituting 
these  values  for  i.  n.  and  found  into  the  postcondition  yields: 


to  ^  i  i.  nO)  ^  Vp  ((1  p  i.  i)  =>  (afpl  s  xU  =>true 

tl  d  n  i.  nO+1)  A  vq  ((n  ^  q  ^  nO)  =>  (alql  ±  x))  =>true 
(i=n  A  x=a[i]  A  found)  V  (i+l=n  a  jfound)  =>  true  for  n=0. 

false  for  nO  >  o 

The  projected  invariant  P  is  in  this  case  therefore: 

P:  ej.iAi_<ndAi_<nAn^n6+l 

A  Vp  (d  ^  p  1  i)  =>  (atpj  1 X)) 

A  Vq  (tn  ^  q  ^  nO)  =>  (alqj  >.  x)) 

The  determinate  has  the  form: 

0:  (i  =  n  A  X  =  a[i]  a  found)  V  (i+1  =  n  a  7found) 

The  determinate  is  true  directly  for  no  =  0.  i.e.  for  the  empty  array  case.  However,  the 
general  problem  requires  that  the  mechanism  will  also  handle  cases  where  no  >  o. 
Note  that  when  the  projection  values  for  /  and  n  are  substituted  into  the  postcondition 
the  antecedents  of  the  two  implications  are  both  false,  however,  it  follows  from  the 
definition  of  implication  that  an  implication  is  true  under  these  conditions. 

Examining  the  invariant  and  the  determinate  we  see  that  a  suitable  bound  func¬ 
tion  IS 

t;  n  -  I  i  0 

The  assignments  i  =  0  and  n  =  nO  -*■  1  establish  that  in  general  x  may  occupy  any  of  the 
positions  in  the  range  i-i-l  ..  n-1  if  it  is  present.  Because  the  data  set  is  ordered  we 
are  therefore  at  liberty  to  examine  the  average  value  of  the  range  still  to  be  considered 
I.e. 

m  :=  ((i+1)  +  (n-D)  div  2 

whicn  simplifies  to 

m  :=  (i+n)  div  2 

There  are  cieariy  three  possible  outcomes  for  each  location  examined. 

(i)  a[m]  <  X  :  In  this  case  we  can  safely  assign  i  :=  m  which  will  maintain  the 
invariant,  decrease  the  bound  function,  and  hence  make  progress  towards 
establishing  the  truth  of  the  determinate. 

(ii)  a[m]  >  X  :  Here  the  assignment  n  :=  m  can  be  safely  made  as  it  maintains 
the  invariant  and  decreases  the  bound  function. 

(iii)  aim]  =  X  :  In  this  situation  it  is  possible  to  make  the  assignments  i  :=  m  and 
n  ;=  m.  These  assignments  will  maintain  the  invariant,  decrease  the  bound 
function  and  presumably  set  up  conditions  for  termination. 

As  all  possibilities  have  been  considered,  we  can  now  specify  the  initialization  and  the 
loop  body. 


As  all  possibilities  nave  been  considered,  we  can  now  specify  me  initialization  ana  me 
loop  body. 

I  :=  0,  n  :=  nO+l; 
do  ?  — > 

m  :=  (i+n)  div  2: 
if  atm]  <  X  — >  I  ;=  m 
0  afml  >  X  — >  n  :=  m 
Q  afml  =  X  — >  I  :=  m,  n  :=  m 
fi 


The  tasK  remaining  is  to  derive  a  suitable  loop  guard.  To  do  mis  we  must  aetermine 
me  maximum  iterative  capacity  for  me  smallest  problem  mat  requires  iterative  solution 
by  tne  loop  body. 


The  smallest  general  problem  that  requires  iterative  solution  is  mat  for  no  =  1.  in  mis 
case  it  the  value  sought  x  were  present  then  the  bound  function  would  be  reduced  oy 
2.  hence  =  2.  We  therefore  have: 

t:  n-i  >.  e 


UJ 

B:' 

B: 


max 


*  -  *^niax 
n-i  >.  2a  1+1 


<  h 


The  detailed  impiementatioh  cah  how  take  the  form: 

Ip  e  i.  hO  — > 

$vr  I,  m,  n  :  integer;  found;booiean  — > 

I  ;=  0,  n  ;=  ne+1: 

$do  1+1  <  n  — > 

m  :=  (i+n)  div  2; 
if  afml  <  X  — >  I  :=  m 
Q  afml  >  X  — >  n  ;=  m 
Q  afml  =  X  — >  I  :=  m.  n  :=  m 
fi 

$od: 

$r:  0  ±  n-i  ±  1  =>  found  :=  (i=n) 

P' 

in  this  example  it  is  only  possible  to  establish  the  truth  of  the  determinate  after  me 
loop  has  terminated. 

Several  comments  are  in  order  about  this  binary  search  derivation  and  imple¬ 
mentation.  The  postcondition  on  which  the  derivation  of  the  algorithm  is  based  is  quite 
different  from  those  usually  used,  it  possesses  a  basic  symmetry  which  is  reflected  m 
the  final  implementation.  The  use  of  quantified  implications  has  avoided  me  need  to 
talk  in  terms  of  +9ftamd  when  dealing  with  x  values  mat  may  be  out  of  bounds  with 
respect  to  tne  given  array  values  (c.f.  other  derivations  f  4.7  ]).  Furthermore,  out-of- 
bounds  cases  do  not  require  any  special  treatment.  A  number  of  other  solutions  nave 
to  treat  tne  empty  array  (i.e.  no  =  e)  as  a  special  case.  The  reason  for  this  follows 
from  me  degeneracy  of  the  postconditions  that  are  usually  employed.  An  often-used 
postcondition  is  built  around: 


1 1  :  ali]  <  X  <  a(i+ll 


The  problem  wim  this  is  that  at  termination  of  the  loop  no  distinction  is  made  between 
a(i]  s  X  and  a[i]  <  x  <  a[i+l].  Hence  an  additional  test  of  the  form: 


founa  :=  (a(il  =  x> 

IS  needed.  This  has  two  disadvantages,  it  must  oe  guarded  to  avoid  an  out-ot-bounds 
array  reference  when  an  empty  array  is  encountered,  and  secondly  one  more  data 
element  comparison  is  applied  than  is  necessary  to  solve  the  problem  (in  fact  tne 
same  comparison  is  applied  twice). 

The  termination  mechanism  for  the  symmetric  binary  search  does  not  allow  termina¬ 
tion  in  a  degenerate  state.  A  simpler  test  can  therefore  be  applied  to  establish  the 
presence  or  absence  of  x. 

Another  interesting  attribute  of  the  algorithm  is  that  it  stops  as  soon  as  the  first  value 
equal  to  x  is  encountered.  It  accomplishes  this  in  a  natural  way  without  having  to 
resort  to  tne  use  of  flags  and  an  additional  boolean  test  in  the  loop  guard. 

Removing  the  assignment  for  m  and  replacing  it  by  i-i-1  leads  directly  to  an 
ordered  linear  search  algorithm  for  which  the  same  postcondition  is  appropriate.  Note 
mat  the  variable  m  is  not  essential.  It  is  also  interesting  to  note  that  an  analogous 
postcondition  to  that  employed  for  the  binary  search  could  have  been  constructed  for 
tne  square  root  problem  discussed  earlier. 

No  apology  is  made  to  those  who  may  suggest  that  the  present  algorithm  is  ‘less  effi¬ 
cient*  than  other  alternatives  when  executed  on  a  sequential  computer. 

4.  On  Loop  Quards  and  Termination 

In  the  preceding  discussion  on  the  binary  search  the  remark  was  made  about  a 
simple  change  that  could  be  used  to  convert  the  binary  search  algorithm  into  a  linear 
ordered  search  algorimrn  satisfying  the  same  postcondition.  The  interesting  thing 
about  the  ‘converted*  linear  search  is  the  way  termination  is  brought  about  when  x  is 
present  -  that  is  by  changing  the  least  upper  bound  n. 

There  is,  however,  at  stake  here  a  much  more  fundamental  issue  which  can  be 
seen  by  considering  a  related  problem,  that  of  searching  an  unordered  array  a[1  ..  nol 
for  some  value  x  with  the  requirement  that  the  algorithm  should  terminate  as  soon  as  x 
is  found  if  it  is  present.  Our  mechanism  should  return  a  boolean  variable  found  that  is 
true  if  X  is  present  and  false  otherwise.  The  mechanism  should  handle  an  cases 
including  the  empty  array. 

A  suitable  postcondition  is: 

R;  (4  i,  I  ^  nO)  A  Vp(1  p  i.  i)  =>  afpl  #  x 
A  (i  =  n)  A  ((n  <  ne  A  X  =  aln+JJ  a  found) 

V  (n  =  ne  A  ifound) 

The  free  variables  associated  with  the  postcondition  are  i.  n  and  found.  Their  ranges 
are: 

i:  (0  .<  I  i.  nO) 

n:  (e^njLnO) 

found:  (false,  true) 

The  role  of  i  is  as  the  greatest  known  lower  bound  on  the  segment  of  tne  array  not 
containing  x  and  the  role  of  n  is  as  the  least  known  upper  bound  of  the  segment  of  tne 
array  not  containing  x.  From  the  ranges  for  the  free  variables  we  can  choose  i  =  e.  n  = 
no,  and  found  =  false  as  the  projection  values.  Substituting  these  values  for  i.  n.  and 
found  into  tne  postcondition  yields: 
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10  j.  I  i.  no)  Vp  (1  1  p  1  i)  =>  a(p]  #  X  =>  true 

(I  =  n)  A  t(n  <  no  A  X  =  atn+1]  a  found)  V  tn  =  no  a  jfound)) 

=>  true  for  no  =  0.  false  for  no  >  0 

The  projected  invariant  P  and  determinate  0  are  therefore  as  given  oeiow: 

P:  (0  i.  1 1  nO)  A  vp  (1  _<  p  ^  i)  =>  a[p]  t  x 

D:  (i  =  n)  A  ((n  <  no  A  X  =  aIn+1]  A  found) 

V  (n  =  no  A  ifound) 

Examining  the  invariant  and  the  determinate  we  see  that  a  suitable  bound  function  is 
t:  n  -  I  >.  0 

The  projection  values  for  i  and  n  establish  that  if  present,  x  may  occupy  any  of  tne 
array  positions  in  the  range  1  to  n.  The  task  at  hand  is  to  examine  the  segment  of  tne 
array  where  it  is  possible  for  x  to  be  located.  As  the  data  is  not  ordered  a  linear 
search  of  the  array  by  advancing  i  under  the  invariance  of  P  is  appropriate. 

There  are  two  possible  outcomes  for  each  location  examined: 

(i)  a(K1]  #  X  :  is  true  in  which  case  we  can  safely  advance  i  by  one  under  tne 
invariance  of  P.  while  decreasing  the  bound  function  and  hence  making  progress 
towards  establishing  the  truth  of  O. 

(ii)  a[l+11  -  X  :  In  this  situation  it  is  not  possible  to  advance  i  under  tne  invariance  of 
P.  However,  it  is  possible  to  decrease  n,  the  least  known  upper  bound  for  seg¬ 
ment  not  containing  x.  This  decrease  in  n,  decreases  the  bound  function  ano  at 
tne  same  time  sets  up  conditions  for  terminating  the  loop. 

As  all  possibilities  have  been  considered  we  can  now  specify  the  initialization  and  the 
loop  body: 

i  :=  0.  n  :=  ne 
do  ?  — > 

if  a(i+lj  ^  X  — >  I  ;=  i+l 
a  aIi+1]  =  X  — »  n  ;=  i 
fi 

00 

Considering  tne  smallest  problem  that  requires  iterative  solution  (i.e.  ne  =  1)  we  dis¬ 
cover  that  IU^aj(  =  1.  Therefore  to  derive  the  guard  we  have: 

t:  n  -  I  >.  e 

Ul  :  1 

t  >  U 

„  -  rnax 

B:  n-i  >.  I  ♦  I  <  n 

The  detailed  implementation  can  therefore  take  the  form: 
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Ip  0  i.  no  — > 

$vr  i,n:integer  — > 

i:*  0.  n  ;=  nO; 

$do  j  <  n  — > 

if  aIi+11  ^  X  — »  i  :=  i+l 
0  a(i+1J  =  X  — >  n  :=  I 
fi 

>od: 

Or;  I  =  n  =>  found  ;=  n  <  no 
pi 

We  have  deliberately  chosen  *i  <  n*  as  our  guard  in  preference  to  ‘i  *  n*  as  we  are  of 
the  conviction  that  the  role  of  the  guard  is  to  protect  the  mechanism  -  *i  ^  n*  does  not 
fulfill  this  role. 

There  are  two  ways  in  which  the  loop  can  terminate.  The  first  involves  *i* 
increasing  stepwise  until  it  reaches  the  value  n.  We  refer  to  this  mode  of  termination 
as  natural  termination.  In  the  other  case,  when  x  is  present,  termination  is  brought 
about  by  reducing  the  upper  bound  n.  We  refer  to  this  as  forced  termination.  We 
reject  the  idea  of  using  the  assignment  i  :=  n  as  an  alternative  means  of  bringing 
about  forced  termination  because  of  its  impact  on  the  loop  invariant. 

It  is  useful  to  introduce  some  additional  terminology  at  this  point.  A  loop  that 
admits  forced  termination  as  well  as  natural  termination  is  said  to  terminate  in  an 
unresolved  state.  Almost  always  it  is  necessary  to  resolve  the  termination  state  of 
such  mechanisms.  We  would  suggest  as  a  principle  of  good  programming  style  that 
this  resolution  should  take  place  after  the  loop  has  terminated  rather  than  in  the  loop 
body.  This  conforms  to  what  we  shall  call  the  law  of  separation  of  concerns  which 
states  that  ‘any  condition  or  mechanism  that  can  obtain  only  in  a  single  iteration  of  a 
loopshould  be  separated  from  the  loop  body". 

The  advantage  of  consistently  applying  this  principle  is  that  it  often  cleans  up  and  sim¬ 
plifies  the  structure  of  loop  bodies,  in  addition,  it  gathers  together  mechanisms  that 
naturally  belong  in  the  post-termination  state.  The  idea  of  keeping  loop  bodies  as 
simple  as  possible  is  important  because  they  are  conceptually  more  difficult  to  analyze 
and  understand  than  non-iterative  components. 

There  is  also  an  important  class  of  problems  where  the  complementary  situation 
applies,  that  is  a  component  of  the  loop  body  apparehtiy  needs  to  be  executed  in  an 
but  the  last  iteration  of  a  loop.  A  methodology  for  handling  problems  of  this  type  is 
discussed  in  sections  5.3  and  5.4. 

Returning  to  our  solution  to  the  linear  search  problem  and  its  relationship  to 
other  solutions  traditionally  offered  for  this  problem  raises  several  important  issues 
about  programming  style.  The  two  traditional  solutions  we  will  give  are  based  on  the 
discussion  by  Feuer  and  Qehani  (  8  ].  (We  have  ignored  solutions  that  employ  sen¬ 
tinels  for  obvious  reasons.) 

The  first  solution  is  implemented  in  Pascal  and  the  second  in  Oijkstra  s  mini- 
language: 

(i) 
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found  :=  false:  i  :=  1 : 

while  (i  s  n)  and  (not  found)  do 
begin 

found  :=  a(i]  =  x; 
i  :=  1+1 

end: 

If  found  then  i  :=  i-l 
(ii) 

I  :=  1: 

do  (i  n)  <  cand  (alll  ^  x>  — >  i  :=  i+l  oo: 

found  :=  1 1  n 

Considering  solution  (i)  first,  we  see  that  the  aim  of  the  program  seems  to  be  to 
terminate  with  i  =  n  if  the  value  sought  x  is  present  m  the  array.  This  is  only  achieved 
as  an  afterthought  by  some  variable  patching  once  the  loop  has  terminated.  When  we 
come  to  looK  for  a  meaningful  invariant  for  this  loop  we  run  into  a  real  headache.  We 
might  initially  be  hopeful  that  part  of  the  invariant  will  be  that  a(1  ..  i-l]  does  not  con¬ 
tain  X.  But  alas,  nothing  as  straightforward  as  this  is  possible.  The  clumsiness  of  this 
solution  IS  attributed  to  Pascal's  lack  of  conditional  logical  operators  (in  this  case 
cand).  It  IS  therefore  suggested  that  the  second  implementation  wmcn  uses  a  condi¬ 
tional  and  (i.e.  cand)  is  a  ‘better  program*  and  so  tne  use  of  conditional  logical  opera¬ 
tors  in  guards  is  to  be  inferred  as  a  good  programming  practice. 

We  would  suggest  that  both  solutions  to  the  problem  are  built  on  poor  formula¬ 
tions.  and  that  they  violate  what  we  would  consider  to  be  several  important  principles 
of  loop  design.  To  uphold  the  spirit  of  structured  programming  we  should  strive  to 
develop  loops  that  have  a  single  point  of  entry  and  exit.  We  would  suggest  that  a 
guard  consisting  of  a  single  condition  conforms  more  closely  to  this  ideal  man  one 
made  up  of  the  conjunction  or  disjunction  of  several  conditions. 

The  use  of  conditional  logical  operators  (which  are  not  implemented  in  ail 
languages  (e.g.  Pascal)  has  an  unnecessary  destructuring  influence.  For  example,  in 
tne  linear  search  (example  (ii)  in  Oijkstra's  mini-language)  forcing  the  condition  a(i]  * 
X  onto  tne  same  level  as  the  test  i  <,  n  destroys  some  of  the  natural  structure  of  tne 
solution  oecause  a[il  *  x  can  only  be  applied  after  it  is  established  that  the  index  test 
is  true. 

Another  point  about  programming  style  that  this  example  brings  out  relates  to  tne 
storage  of  the  n  array  elements  in  a[e..n-l]  rather  than  the  more  conventional  storage 
of  the  n  elements  in  a[l..n].  For  this  (ii)  would  have  the  following  form: 

(ii') 

i  :=  e 

00  I  ^  n  cand  (a[i]  ^  x)  — >  i  :=  i+1  od; 

found  :=  I  <  n 

While  in  practice  both  formulations  are  perfectly  valid,  the  former  is  an  unneces¬ 
sary  complication  which  causes  some  confusion  because  of  the  way  ‘i*  is  given  its  two 
roles.  It  must  act  firstly  as  a  counter  for  the  number  of  array  elements  processed  and 
secondly  as  an  array  index.  Using  the  convention  a[e..n-1]  the  two  roles  are  need¬ 
lessly  out  of  step  by  one.  After  one  iteration  it  would  seem  more  natural  for  the  first 
element  a(1]  to  have  been  processed  and  i  to  reflect  a  count  of  1.  Our  implementation 
uses  ati+l]  to  accomplish  this  in  a  straightforward  manner.  The  ‘+1*  allows  tne 
mechanism  to  ‘peak-ahead*  and  then  make  the  necessary  adjustments  to  maintain 
tne  invariant.  The  other  mechanism  (ii')  must  also  achieve  lookahead,  it  does  this  by 
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naving  tne  index  i  of  tne  array  (after  eacn  iteration)  always  pointing  at  the  next  element 
to  oe  processed  rather  than  at  the  element  that  has  just  been  processed.  On  termina¬ 
tion  *i*  may  point  beyond  the  valid  array  indices  (i.e.  since  a(nl  is  not  defined).  These 
characteristics  make  the  a[e..n-1]  scheme  semanticaliy  clumsy. 

Several  other  comments  are  in  order,  in  the  light  of  tne  proposed  alternative 
methodology  for  constructing  loops.  One  of  the  cornerstones  of  this  methodology  is 
tne  requirement  that  the  guard  for  a  loop  should  be  intimately  related  to  the  bound 
function  and  to  the  iterative  capacity,  in  contrast  tests  like  a[i]  #  x  and  (not  found)  used 
in  (1)  and  (ii)  bear  no  direct  relationship  to  the  bound  function.  Also,  in  the  interests  of 
proving  termination,  we  would  suggest  that  such  tests  should  be  excluded  from  loop 
guards. 

Further  weight  is  added  to  this  suggestion  if  we  re-examine  how  our  original 
linear  search  algorithm  was  derived.  Projection  of  tne  invariant  from  the  postcondition 
Clearly  established  that  alp]  #  x  belonged  to  the  invariant,  radier  than  the  guara. 
Thankfully  our  methodology  conforms  to  what  might  be  considered  as  good  program¬ 
ming  practice. 

Yet  another  way  to  think  about  this  problem  is  to  consider  that  guards  should  oe 
defined  for  complete  domains  whereas  conditions  that  have  the  potential  to  force  early 
termination  are  subordinate  and  therefore  belong  in  the  body  of  the  loop.  Applying 
these  ideas  our  integer  square  root  algorithm  can  take  a  form  analogous  to  the  linear 
search  i.e. 

a  ;=  e.  n  :»  nO; 
do  a  <  n 

if  (a+1)^  1  no  =»  a  :*  a+1 
0  (a+l)^  >  ne  — »  n  :=  a 


As  we  shall  see  in  many  of  the  examples  to  be  discussed  the  method  of  termina¬ 
tion  we  have  proposed  has  wide  application.  An  explanation  why  it  has  not  been  widely 
used  in  tne  past  is  probably  due  to  the  influence  of  languages  like  Fortran  which  nave 
required  a  fixed  upper  limit  on  loops. 

The  same  principles  can  be  applied  to  other  data  structures.  For  example,  con¬ 
sider  tne  three  implementations  in  a  Pascal-like  language  which  search  for  some  ele¬ 
ment  x. 


(1)  Array 


I  :=  e,  n  :=  no; 

do  I  ^  n  — > 

if  a[i+ll  ^  X  — >  I  :=  i+l 
□  a{i+)J  =  X  — >  n  ;=  I 
fi 

oa: 

found  n  ^  no 


(11)  Line 


i 

W 

£ili 

s 

ITOr 


St* 
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no  :=  true: 

I  :=  eoin  (input),  n  :=  no: 

00  I  #  n  — > 

if  input  t  #  X  — >  get  (input),  i  :=  eoln  (inpuU 
0  input  t  =  X  — >  n  :=  I 
fi 

00 : 

founo  :=  n  ^  no 


(Hi)  List 

no  :=  nil: 

I  :=  listheao.  n  :=  no: 

00  I  ^  n  — > 

if  i  t.info  ^  X  — >  I  ;=  it.link 
0  it. into  =  X  — >  n  :=  I 
fi 

00 : 

founo  ;=  n  ^  no 

in  tnese  examples  we  see  now  exactly  the  same  control  structure  is  useo  for  ail 
tnree  implementations.  There  are  obviously  a  number  of  aovantages  in  using 
representation-inOepenOent  control  structures. 

It  IS  equally  possible  to  apply  me  same  techniques  for  file  operations  with 
languages  like  Coboi  which  oo  not  have  the  same  looKaneaO  facilities  as  nave  been 
employee  here. 

From  a  mothodological  standpoint  it  manes  a  lot  of  sense,  in  appropriate  applica¬ 
tions.  to  develop  solutions  as  //  we  were  dealing  with  arrays  of  data.  This  maxes  it 
easier  to  oefine  bounO  functions  anO  prove  termination.  The  type  changes  ano  me 
Orawing  of  corresponoences  among  such  constructs  as  a(i-«-1].  inputt  ano  it. info  etc. 
IS  essentially  a  mechanical  process.  From  a  peOagogical  viewpoint  there  are  also 
aovantages  in  that  relatively  OetalleO  solutions  to  problems  can  be  presentee  which 
are  essentially  transparent  to  the  Oata  representation. 

Of  course  some  will  argue  that  we  have  maoe  me  list  ano  file  processing  more 
compiicateO  than  neeO  be  by  introOucing  more  variables  than  are  necessary  to  solve 
me  problem.  Before  rejecting  our  proposal  out-of-hano  as  just  a  programming  tricx. 
we  wouiO  urge  the  reaOer  to  consiOer  carefully  the  Oeeper  implications  mat  it  may 
have  for  oeveioping  programs. 

In  the  sections  which  follow  we  will  frequently  use  ano  builo  on  tne  techniques 
which  we  have  oescribeo  in  this  section.  On  a  number  of  occasions  we  will  oeai  with 
problems  which  are  traOitionaliy  list  or  file  orienteo.  In  the  light  of  the  present  oiscus- 
sion  we  will  usually  Oeal  with  these  problems  using  arrays.  However,  they  shoulO  be 
seen  as  general  solutions  with  control  structures  which  can  conveniently  accommo- 
oate  other  Oata  representations. 

5.  Inductive  Refinement  and  Loop  Construction 

‘Beauty  is  the  first  test  -  there  is  no  permanent  place  in  computing 

for  ugly  programs* 

(with  apologies  to  Q.H.  Hardy) 

In  me  examples  we  have  considered  thus  far  me  relationships  among  tne  bound 
functions,  invariants  and  loop  bodies  have  been  clear-cut.  As  we  move  to  slightly 
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more  compiicatea  problems  it  is  useful  to  apply  a  more  powerful  constructive  metno- 
ooiogy.  The  guiding  principle  that  is  widely  accepted  by  program  designers  for  deal¬ 
ing  with  non-triviai  problems  is  top-down  design  or  stepwise  refinement.  This  strategy 
IS  essentiaily  a  deductive  one.  in  that  the  underlying  constructive  principle  involves 
making  transitions  from  the  general  to  the  specific. 

As  a  method  for  breaking  down  problems  into  intellectually  manageable  com¬ 
ponents.  top-down  design  is  admirable.  Me  would,  however,  suggest  that  for  many 
problems,  once  this  level  of  description  has  been  reached,  top-down  design  often  fails 
to  provide  the  constructive  insight  that  we  might  hope  for  from  such  a  design  strategy. 
In  sucn  circumstances  it  is  often  more  appropriate  and  more  natural  to  apply  what  we 
shall  describe  as  inductive  stepwise  refinement.  The  point  in  the  program  develop¬ 
ment  process  where  it  is  most  appropriate  to  apply  inductive  refinement  is  where  we 
have  a  detailed  and  well-formed  postcondition  for  an  explicit  task  or  sub-task.  When 
inductive  refinement  is  introduced  under  these  conditions  it  can  be  directly  related  to 
details  of  the  postcondition.  At  the  same  time  it  is  often  possible  to  effectively  apply 
inductive  refinement  without  having  formally  and  explicitly  defined  the  postcondition  in 
terms  of  predicates  etc. 

The  guiding  constructive  principle  employed  by  inductive  refinement  is  to  start  on 
me  development  of  a  solution  to  a  problem  by  identification  of  the  associated  ii- 
mecnanism.  Repeating  our  earlier  definition  the  li-mechanism  is  the  weakest  iterative 
mechanism  capable  of  establishing  the  postcondition.  Having  identified  the  ii- 
mechanism  inductive  stepwise  refinement  can  then  proceed  by  a  sequence  of  gen¬ 
eralizations  until  the  mechanism  has  been  refined  to  the  stage  where  we  nave  an 
implementation  for  the  general  problem  that  we  originally  set  out  to  solve. 

At  first  sight  it  may  appear  that  what  we  are  advocating  is  a  traditional  bottom-up 
approach  to  program  design.  As  succinctly  pointed  out  by  Turski  [  9  ],  bottom-up 
design  as  traditionally  employed  is  useful  for  creating  software  tools  but  is  not  gen¬ 
erally  regarded  as  a  ‘problem-directed*  programming  methodology,  in  contrast  to 
this,  inductive  refinement,  because  of  its  explicit  relationship  with  the  postcondition  is 
a  strongly  problem-directed  methodology.  This  relationship  with  the  postcondition 
gives  the  method  much  more  power  and  direction  than  traditional  bottom-up  design. 
We  would  see  the  role  of  inductive  refinement  as  one  of  complementing  the  top-down 
development  m  the  process  of  program  design. 

Polya  in  his  classic  works  on  Mathematical  problem-solving  (  10  ]  gives  an  excel¬ 
lent  account  of  the  importance  and  constructive  role  of  induction  (as  distinct  from 
matnematicai  induction)  in  the  solution  of  problems.  Just  as  the  outcome  of  a 
mathematician's  creative  work  is  demonstrative  reasoning,  so.  too.  should  be  a  fin- 
isned  program,  for  such  reasoning  provides  a  means  of  securing  (as  opposed  to 
creating)  knowledge  in  a  science.  The  computing  science  literature  cieariy  reflects 
this  bias.  Computing  scientists  should,  however,  not  neglect  knowledge  concerned 
with  the  construction  of  programs.  Efforts  in  this  direction  have  unfortunately  placed 
very  little  emphasis  on  the  possible  use  of  induction. 

in  general,  to  effectively  apply  induction  in  the  solution  of  a  problem  the  choice  of 
an  appropriate  or  relevant  starting  point  is  crucial.  We  would  suggest  that  in  employ¬ 
ing  induction  in  program  development  the  ii-mechanism  can  often  fulfill  the  roie  of  an 
appropriate  starting  point.  We  will  not  continue  to  argue  further  in  favour  of  the  role  of 
induction  in  program  development.  The  reader  is  invited  to  consider  the  examples 
Which  follow  and  make  his  or  her  own  conjectures  about  its  value. 

Before  we  can  come  to  grips  with  the  application  of  the  inductive  refinement 
methodology  we  must  re-examine  the  underlying  nature  of  the  iterative  process  and 
men  see  the  implications  that  this  has  for  our  present  circumstances.  The  basic 
structure  we  are  referring  to  is: 
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initialization; 

00  B  — > 

Loop-DoOy 

00 

The  role  of  the  initialization  is  twofolO.  Firstly  to  proviOe  a  solution  to  the  smallest 
proDiem  (non-iterative)  that  the  mechanism  is  OesigneO  to  hanOle.  SeconOly.  it  must 
proviOe  the  setup  for  problems  that  require  iterative  solution. 

When  it  IS  necessary  to  oeai  with  more  complex  loop  structures,  wnere  we  nave 
an  Iterative  process  (i.e.  another  loop)  embeOOeO  inslOe  a  loop  we  neeo  to  re-examine 
What  is  tne  most  appropriate  initialization  for  both  the  inner  and  the  outer  loops, 
remembering  that  all  loops  require  some  form  of  initialization.  Working  to  this  basic 
loop  design  principle  one  fairly  obvious  structure  for  problems  where  we  have  a  loop 
within  a  loop  is: 

Initialization  (for  outer  loop): 
doB  -> 

Initialization  (for  inner  loop): 
do  B,  —> 

Loop-body 

od 

od 

What  we  need  to  recognize  is  that  the  outer  loop  has  the  obvious  roie  of  applying  an 
Iterative  process  (i.e.  the  inner  loop  and  its  initialization)  repeated/y.  We  can  regard 
the  initialization  for  the  outerioop  as  a  ‘Static  mttialization'  because  it  is  only  applied 
once  Whereas  the  initialization  for  the  inner  loop  is  a  ‘dynamic  initialization'  in  that  it 
can  be  applied  repeatedly.  The  relationship  between  the  static  and  dynamic  initializa¬ 
tions  can  have  an  important  influence  on  the  composition  of  the  loops.  We  will  also 
see  how  this  relationship  can  be  used  to  help  charac^terize  and  categorize  loop  struc¬ 
tures  into  different  classes. 

5.1.  Static  Initialization 

Probably  tne  simplest  nested  loop  structures  are  those  that  effectively  require 
only  a  static  initialization  for  the  inner  loop.  We  will  now  consider  an  example  from  this 
Class  because  it  gives  a  simple  demonstration  of  how  a  ii-mechanism  can  be  used  to 
help  solve  a  problem.  The  example  also  illustrates  how  the  ideas  for  early  termination 
of  loops  can  be  exploited. 

Example  5.1  Searching  a  two-dimensional  array 

This  problem  involves  searching  a  two  dimensional  array  all  ..  me.  1  ..  nei  for 
some  value  x.  if  x  is  present  in  the  array  the  mechanism  should  return  indices  that 
can  be  used  to  identify  the  row  and  column  where  x  was  located.  A  boolean  variable 
found  should  also  be  established  and  set  to  true  if  x  is  present,  and  set  to  false  other¬ 
wise.  The  algorithm  should  terminate  as  soon  as  x  is  found  if  it  is  present  Given 
these  requirements  we  may  propose  the  following  postcondition  as  suitable  for  use  in 
developing  the  searching  algorithm. 

R:  (0  .<  I  jL  me)  ^  (0  nd)  ^  Vp.q 

(1 p I)  ^  (1  .<  q  ij)  =>  afp.qj  ^  x  ^  (i  =  m)  ^  (j  *  n) 

^  ((m  <  me  ^  X  =  a  fm+1.  n  mod  ne+lJ  ^  found)  V 
tm  =  me  A  ifound)) 

in  tne  postcondition  m  is  the  greatest  known  lower  bound  for  the  complete  rows  not 
containing  x  and  n  is  the  least  known  upper  bound  for  columns  not  containing  x 
corresponding  to  an  assigned  row  value. 


The  ranges  associated  with  the  variahies  in  R  are: 

i:  (6  i,  1 1  m4)  j:  1  j  nOm:  (0  m  mO)  n;  (0  i  n  i.  no) 

We  can  choose  as  projection  values  tor  these  vanaoies  i  e.  j  =  e,  m  =  me  and  n  =  no. 
Projecting  the  invariant  P  and  determinate  0  from  the  postcondition  R  we  get: 

P:  (e  1 1 1  me)  rs,*  (e  ij  ^  ne)  /\V  p.q 
tl  ^  p  1  i)  ^  (1 1  q  1  j)  =>  afp.ql  *  x 
0:  I  =  m  Aj  =  n  z''  ((m  <  me  A  x  =  a(m+l.  n  moo  ne+11  A  found) 

V  im  =  me  A  I  found) 

A  possiOte  Dound  function  would  be 
t:  m-i  +  n-  jie 

Our  task  now  is  to  develop  a  loop  tnat  will  decrease  the  Pound  function  with  eacn 
Iteration.  Applying  the  inductive  refinement  methodology  we  are  looking  tor  m  the  first 
instance,  the  weakest  iterative  mechanism  capable  of  establishing  the  postcondition  R. 
To  make  progress  towards  establishing  R  we  nave  four  options,  decreasing  m.  and  n 
or  increasing  i  and  j.  The  weakest  possible  mechanism  is  one  that  will  only  need  to 
Change  one  of  these  four  variables.  For  example  a  mechanism  that  changed  just  the  j 
index  (except  possibly  on  termination)  and  which  could  terminate  on  finding  x  would 
qualify  as  the  li-mechanism.  It  processes  a  single  row  of  the  array. 

j:=  e.  i:=  0: 
do  J  <  n  => 

if  a[i+1,j+l]  ^  X  — >  j:=  j+1 
0  a(i+l.j+l]  =  X  — >  n:=  j 
fi 

od 

This  loop  can  terminate  in  only  one  of  two  ways,  with  x  found  and  the  least  known 
upper  bound  for  the  segment  not  containing  x  redefined,  or  with  it  established  that  x  is 
not  in  the  specified  row. 

The  mechanism  we  have  described  is  only  sufficient  to  process  a  single  row  of  a 
two  dimensional  array.  To  solve  our  original  problem  our  mechanism  must  be  gen¬ 
eralized  so  that  it  can  handle  a  two  dimensional  array  with  more  than  one  row.  Under 
these  conditions,  to  make  further  process  towards  termination  it  will  be  necessary  to 
Change  another  variable  i,  (ie  the  row  variable).  Each  row  can  be  processed  in 
essentially  the  same  manner  and  so  the  generalization  to  the  processing  of  mo  rows  is 
straightforward.  All  that  is  needed  is  to  apply  the  single  row  mechanism  repeatedly 
until  either  x  is  found  or  it  has  been  established  that  x  is  not  present  m  all  rows.  At  the 
point  where  it  is  established  that  x  is  present,  using  our  original  mechanism  it  is  impli¬ 
cit  that  the  least  upper  bound  on  the  number  of  complete  rows  not  containing  x  is 
redefined.  This  step  must  oe  included  explicitly  (ie  by  m  :=  i)  when  our  mechanism  is 
generalized  to  handle  more  than  one  row.  This  assignment  also  has  me  effect  of  ter¬ 
minating  the  row  searching  as  soon  as  x  is  found.  We  are  therefore  led  to  the  follow¬ 
ing  implementation. 
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Ip  0  1  mP  ‘  6  j.  nd  — > 

$vr  i.|,m.n:integer  — > 
i:=6,  m;=m6; 

$do  I  <  m  — > 
j:=d.  n  ;=  nO; 

do  j  <  n  — > 

if  a[i+l ,  j+1]  ^  X  — >  j:=  j+l 
a  ali+l,j+l]  =  X  — >  n;=  j.  m:=  i 
fi 

od: 
i:=  i+1 
$od 

$r;  m  ^  mo  *  n  i.  nd  =>  found  :=  m  <  mo 

in  handling  termination  for  this  problem  we  have  applied  the  principles  that  were  out¬ 
lined  in  the  previous  section  for  cleanly  terminating  loops. 

It  is  interesting  to  compare  the  above  solution  to  the  problem  with  the  solution 
given  by  Ones  ([  4  ]  pp  183-184).  Our  mechanism  has  the  same  underlying  structure 
as  the  mechanism  we  used  to  solve  the  corresponding  one  dimensional  problem.  This 
IS  somewhat  reassuring.  Gries'  algorithm  uses  only  a  single  loop  to  solve  the  prob¬ 
lem.  It  could  be  argued  that  this  amounts  to  a  superior  simplification  of  the  problem 
over  our  nested-loop  solution.  On  the  other  hand  it  can  be  argued  with  equally  as 
much  weight  that  the  problem  is  two-dimensional  and  therefore  naturally  supports  a 
nested-  loop  implementation.  The  guard  used  by  Gries  has  the  form 

B:  i  m  cand  x  *  ad.j] 

In  contrast,  our  method  of  projecting  the  invariant  from  the  post  condition  naturally 
relegates  the  test  involving  x  to  the  loop  body.  Gries'  implementation  relies  explicitly 
on  the  use  of  the  cand  operator  in  the  guard.  Hence  his  solution  is  probably  more 
language  dependent  than  is  desirable.  We  would  suggest  that  the  logical  components 
of  a  guard  should,  if  at  all  possible,  have  a  direct  relationship  with  the  bound  function. 
X  *  a(i.  j].  certainly  does  not  have  this  property. 

In  summary,  this  problem  which  m  essence  is  relatively  simple,  causes  most 
adherents  of  structured  programming  considerable  discomfort  particularly  if  they  are 
unwilling  to  resort  to  either  cands.  breaks  or  gotos.  We  would  suggest  that  our  solu¬ 
tion  conforms  naturally  to  structured  programming  principles. 

5.2.  inductive  Initialization 

We  will  now  move  onto  a  set  of  examples  that  employ  a  simple  form  of  dynamic 
initialization  for  the  inner  loop. 

Example  5.2  The  Inventory  Report  Problem 

The  inventory  report  problem  is  a  well-known  programming  problem,  in  present¬ 
ing  the  problem  we  have  stripped  away  most  of  the  extraneous  detail  so  that  we  can 
concentrate  on  tne  methodological  issues  that  the  problem  raises.  Stated  in  its  sim¬ 
plified  form  we  are  given  two  arrays  of  length  ne.  The  first  array  is  a  product-identifier 
array  which  contains  a  set  of  incoming  and  outgoing  transactions  for  various  products, 
ordered  by  their  product  identifier.  The  elements  in  the  second  array  form  a  one-to- 
one  correspondence  with  the  elements  m  the  first  array.  The  elements  stored  in  this 
array  are  positive  or  negative  quantities  each  representing  a  particular  transaction  for 
the  corresponding  product  m  the  first  array. 
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Schematically  the  data  may  be  represented  as: 
product  g1  g1  g1  g2g2g3g3.... 

transaction  -7  +2  +6  +2  +9-9-6.... 

The  task  at  hand  is.  given  the  information  about  transactions,  to  produce  a  report  of 
the  net  quantity  of  each  product  currently  held  in  stock. 

Sets  can  be  used  to  give  the  simplest  description  of  the  postcondition.  We  have 

Q  -  5  Qi  with  Qi  n  Qj  s  e  for  all  l  j 

Tl  =  2tg 
geGi 

Here  Q  represents  the  union  of  all  products  and  tg  is  a  transaction  for  product  Qi.  With 
these  definitions  our  postcondition  takes  the  form 

R:  (Oii^W  AVp  (i^p^O  =>  CT^=  ^  A(i  =  k) 

—  —  r  —  r  —  p  g£(3i 

Our  formulation  of  the  problem  has  hidden  the  explicit  count  of  the  total  number  of 
transactions  ne  that  need  to  be  processed.  This  will  obviously  need  to  be  accommo¬ 
dated  in  our  implementation.  Projecting  the  invariant  and  the  determinate  from  the 
postcondition  using  i  =  e  we  get: 

P:  (0  1  i)  A  (i  _<  k)  A  Vp  (1  ^  p  ^  I)  =>  T-  =  £  tg 

P  geGp 


in  general  the  data  may  consist  of  one  or  more  products  and  for  each  product 
there  may  be  one  or  more  transactions.  In  the  first  instance  we  are  looking  for  me 
weakest  iterative  mechanism  capable  of  establishing  the  postcondition,  it  is  possible 
that  we  may  have  to  deal  with  only  one  product  for  which  there  may  be  more  than  one 
transaction.  A  mechanism  to  solve  this  problem  would  correspond  to  the  n- 
mecnanism  for  the  general  problem. 

In  formulating  the  TT-mechanism  to  total  the  transactions  for  a  particuier  product 
it  is  implicit  that  all  the  transactions  are  for  that  product.  Therefore  to  be  strictly 
correct  in  formulating  our  IT-mechanism.  we  should  include  a  check  to  ensure  that 
transactions  for  only  one  product  are  being  processed.  Termination  should  take  place 
if  it  is  found  that  there  are  transactions  for  other  than  the  particular  product  being  pro¬ 
cessed.  OurTi-mechanism  can  therefore  take  the  form 

j  :=  1,  n  :=  nO: 

T  :=  Ujl; 

do  j  <  n  — > 

if  gtiJ  =  — >  j.  T  ;=  j+f .  t+mi+ii 

a  gfji  *  on+iJ  — >  n  :=  i 

fi 

od: 

write  (g(j],  T) 

Notice  that  this  loop  will  total  all  transactions  for  a  single  product,  if  another  proouci 
IS  encountered  the  algorithm  immediately  terminates. 

As  was  stated  earlier  for  the  general  case  we  win  need  to  be  able  to  handle  nK>re 
man  one  product.  By  applying  the  process  that  will  handle  a  single  product  iteratively 
over  all  products,  we  will  achieve  the  generaii2ation  necessary  to  solve  our  original 
problem.  This  generalization  is  relatively  straightforward.  Wim  eacn  iteration  our 
refined  mechanism  we  will  require  that  another  product  has  been  processed. 
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Our  final  algorithm  can  therefore  take  the  form: 

ip  0  i.  no  — > 

$vr  j.n.T;  integer  — > 

j  :=0; 

WO  j  <  no  — > 

n  :=  no; 

).  T  :=  j+1.  tfj+l]; 

00  1  <  n  — > 

if  g[j]  =  g(j+13  — >  |.  T  :=  j+l,  T+t(j+11 
D  gfjl  *  g[j+iJ  — >  n  :=  I 

00; 

write  (g[jl.T) 

$00: 

$r:  I  =  no  =>  true 
P' 

in  making  the  generalization  to  oeal  with  more  than  one  proouct  the  only  change 
necessary  was  to  ensure  tnat  the  initialization  for  the  proOuct-processing  loop  was 
maoe  Oynamic  Dy  introOucing  the  assignment  j  :=  j-i-1  in  place  of  j  ;=  1.  Solutions  to 
this  problem  have  been  Oiscusseo  at  length  in  a  recent  review  of  programming  metho- 
ooiogies  given  by  Berglano  (111.  Essentially  the  same  problem  has  also  been  Ois¬ 
cusseo  by  Jackson  [  5  1.  Berglano.  who  Oescribes  the  problem  as  the  ‘McDonald's 
problem*  gives  two  solutions  of  interest,  one  that  was  derived  using  Jackson's  metho¬ 
dology  and  a  second  solution  that  was  derived  using  Oijkstra's  methodology.  The 
Jackson-style  solution  which  reads  the  data  from  a  file  with  a  Cobol-type  read  has  the 
following  form: 

read  (g2.t): 
do  while  (not  eof) 

T  :=  e; 

gl  :=  g2; 

00  while  (gl  =  g2)  and  (not  eoO 
T  T*t; 
read  (g2.t) 

00; 

write  (gl.T) 

00 

Our  present  algorithm  is  superficially  quite  close  to  Jackson's  and  Bergiand's 
solutions,  however  the  difference  which  exists  raises  what  we  consider  are  several 
important  methodological  issues  of  loop  construction.  The  difference  occurs  in  the 
way  the  initialization  is  handled  for  the  loop  that  does  the  processing  of  all  the  tran¬ 
sactions  for  a  given  product.  Mfe  take  the  view  stated  earlier  that  the  initialization  for  a 
loop  should  account  for  the  smallest  defined  problem  that  the  loop  is  required  to  solve  - 
in  this  case  that  of  dealing  with  a  single  transaction  for  a  particular  product.  Neither 
the  Jackson  nor  the  Bergiand  solutions  conform  to  this  ideal  for  initialization.  As  a 
result  their  loops  are  always  forced  to  execute  at  least  ohce  with  the  consequence  that 
the  tests  (gl  =  g2)  and  (not  eoO  are  executed  needlessly  once  for  each  iteration  of  the 
outer  loop. 

A  second  fundamental  issue  that  the  differences  in  implementation  raises  relates 
to  the  progress  that  the  outer  loop  is  seen  to  make  with  each  iteration.  This  progress 
tor  Jackson  and  Bergiand's  solutions  (ie  the  reading  of  the  next  transaction  from  the 
file)  IS  hidden  within  the  inner  loop.  We  consider  this  to  be  a  poor  design  principle  as 


II  maKes  progress  towards  termination  of  tne  outer  loop  totally  oepenoent  on  tne  inner 
loop.  This  makes  proving  termination  of  the  outer  loop  more  complicated  than  is 
necessary. 

It  should  be  stressed  that  the  issues  that  we  have  raised  with  this  problem  are  not 
artefacts  of  the  fact  that  we  have  worked  with  arrays  rather  than  files  that  require  either 
Pascal-like  or  Cobol-like  read  operations.  Our  implementation  can  be  converted  to 
either  of  the  file  solutions  by  straightforward  application  of  the  techniques  described  in 
tne  preceding  section. 

Bergland  [  11  }  suggests  that  this  problem  illustrates  two  important  advantages  of 
Jackson  s  methodology.  The  first  advantage  is  that  the  methodology  yields  a  solution 
'that  seems  to  model  tne  problem  best'.  The  need  to  iterate  over  ail  transactions  for  a 
product  and  tnen  over  ait  products  would  seem  to  naturally  suggest  a  structure  con¬ 
sisting  of  two  loops.  While  we  are  in  agreement  with  the  observation  about  the  natural 
structure  of  tne  problem  we  would  suggest  that  the  solution  obtained  by  inductive 
refinement  arrives  at  the  same  goal  for  a  deeper  reason.  What  we  are  claiming  is  that 
the  inductive  refinement  methodology  should,  if  correctly  applied,  yield  solutions  that 
naturally  follow  tne  innerent  data  structure  in  the  problem.  This  should  follow  because 
tne  underpinning  constructive  principle  being  applied  always  attempts  to  establish  tne 
postcondition  by  changing  the  least  number  of  variables.  Subsequent  generalizations 
required  also  apply  the  same  principle.  We  will  attempt  to  demonstrate  in  subsequent 
examples  that  the  scope  for  application  of  these  principles  appears  to  be  considerably 
wider  than  a  methodology  that  is  tied  to  data  structuring. 

The  second  advantage  of  Jackson's  methodology  noted  by  Bergland  is  that  'peo¬ 
ple  are  more  likely  to  derive  the  preferred  solution  using  data  structure  design  than  by 
any  of  the  other  methods'.  We  are  not  prepared  to  argue  one  way  or  another  whether 
this  IS  true.  We  would,  however,  suggest  from  somewhat  limited  experience,  that 
inductive  refinement  has  at  least  as  much  potential  as  Jackson's  methodology  for 
consistent  application.  This  follows  from  the  fact  that  the  weakest  Iterative  mechanism 
for  establishing  the  postcondition  is  usually  well  -  defined.  Subsequent  generaliza¬ 
tions  should  also  follow  consistently. 

As  a  second  point  of  reference  it  is  worthwhile  making  a  few  brief  comments 
about  tne  solution  quoted  by  Bergland  that  was  derived  using  Oijkstra's  methodology. 
This  solution  uses  a  single  loop  to  solve  the  problem  and  consequently  does  not  make 
explicit  tne  two  modes  of  iteration  i.e.  iteration  over  transactions  for  a  product,  and 
Iterations  over  products.  It  has  the  form: 

ml,  I.  cl  :=  1,  0,  0; 
do  m  1  ^  m  — > 

if  f[m1]  =  f[m1  +  l]  — >  cl  ;=  cl+qlmll 

a  ffml]  *  f[ml  +  l]  — >  i  :=  i+l;  c[ij  :=  cl+qlmU,  cl  ;=  0 

fi; 

ml  ;=  ml  +  1 
od 

in  one  sense  this  solution  is  'simpler'  than  any  of  the  previous  solutions  but  we  would 
suggest  that  the  simplicity  has  been  gained  only  at  the  expense  of  a  more  complicated 
invariant,  introduction  of  a  sentinel,  and  a  destruction  of  the  natural  structure  of  tne 
problem. 

We  would  suggest  mat  this  mechanism  'lags  one  step  behind’  which  makes  it  more 
difficult  to  characterize  cl  with  an  invariant  properly.  Our  other  criticism  is  that  the 
algorithm  relies  on  the  use  of  a  sentinel  to  handle  termination,  a  practice  which  we 
would  consider  should  be  avoided. 
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As  a  final  contrast  between  mouctive  refinement  and  Dijkstra's  metnodoiogy  we  would 
suggest  tnat  tne  present  example  illustrates  that  inductive  refinement  is  not  neces¬ 
sarily  so  heavily  dependent  on  naving  a  precise  mathematical  formulation  of  tne 
postcondition.  This  suggestion  is  not  intended  to  imply  that  it  is  unnecessary  to  estao- 
lisn  a  precise  mathematical  formulation  of  the  postcondition.  To  the  contrary,  we 
would  claim  that  the  more  precisely  the  postcondition  is  formulated  tne  more  explicit  is 
the  guidance  that  inductive  refinement  can  give  in  the  constructive  development  of 
algorithms. 

Example  5.3  Prime  Factorization 

The  problem  of  prime  factorization  illustrates  several  useful  points  about  loop 
construction.  The  problem  has  been  discussed  in  some  detail  by  Alagic  and  Arbib  [  12 
J.  in  discussing  the  problem  we  will  attempt  to  formulate  the  algorithm  so  that  it  meets 
their  requirements  as  we  subsequently  wish  to  make  a  comparison  with  their  imple¬ 
mentation.  This  involves  explicitly  saving  an  array  of  all  factors  including  multiple 
occurrences,  it  nas  been  assumed  that  a  source  of  ail  ordered  primes  is  available  in 
an  array,  in  our  solution  we  will  assume  tnat  there  is  a  function  available,  called 
nextprime.  which  returns  the  next  prime  when  given  the  current  prime.  This  function  is 
to  be  initialized  by  giving  it  tne  starting  value  1.  A  precisely  formulated  postcondition 
for  this  problem  is  rather  unwieldy.  We  will  give  a  somewhat  simplified  version  of  R. 
Given  tne  integer  zo  to  be  factored,  the  ordered  primes  P^.  Pg.  ...  P^^.  and  tne 
corresponding  exponents  e^.  e^.  ...  ej^  wnicn  are  all  greater  tnan  or  equal  to  zero,  we 
can  write  our  postcondition  as 

R;  (1.<z^ze)  "A  •  '^2^  ...  =  z0 

''•Vqtl^q^i)  z  moo  pq  F  0  A2=i  Aiss(< 

At  this  stage  we  could  go  ahead  and  project  out  the  invariant  and  determinant 
and  proceed  as  we  have  done  previously,  instead  we  will  attempt  to  snow  how  induc¬ 
tive  refinement  can  oe  applied  to  develop  tne  algorithm  without  having  to  reiy  on  a 
precise  formulation  of  tne  postcondition. 

If  we  are  to  proceed  along  these  lines  we  must  first  ask  the  question,  wnat  is  the  weak¬ 
est  Iterative  mechanism  that  could  solve  me  problem?  This  would  obviously 
correspond  to  the  situation  where  the  integer  zb  is  equal  to  a  single  prime  (in  tne  sim¬ 
plest  case  tne  first  prime)  raised  to  some  power.  To  solve  this  problem  we  will  need  to 
reduce  tne  number  to  oe  factored  by  repeated  division  by  p  until  p  will  no  longer  divide 
into  tne  quotient.  Our  ii-mechanism  can  therefore  take  the  form: 

z  :=  zo.  p  :=  1.1  :=  b; 

p  ;=  nextprime (p); 

00  z  mod  p  =  o  — > 

I,  z,  f[i+l]  :=  1+1.  z  div  p,  p 

00 

If  our  mechanism  is  to  handle  the  case  where  ze  may  contain  more  than  one  prime 
factor  we  will  need  to  generalize  tne  mechanism  so  mat  other  prime  factors  can  oe 
tried.  To  do  this,  ail  we  will  need  to  do  is  apply  our  ii-mecnanism  iteratively.  This 
brings  us  to  the  problem  of  deciding  under  what  conditions  should  our  more  general 
mechanism  terminate.  Obviously  our  mechanism  can  only  be  applied  while  the  primes 
being  considered  as  factors  are  less  man  or  equal  to  z. 

We  can  therefore  propose  as  our  prime  factorization  algorithm  me  following  imple¬ 
mentation: 
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z  ;=  »,  p  :=  1, 1  ;=  ■ 

00  Zi  p  — > 

p  ;=  nextprime(p): 

00  z  mod  p  =  0  — > 

i,  z,  f[i+1]  :=  1+1,  z  div  p,  p  i 

00  I 

od 

At  this  point  we  might  be  content  with  the  solution  we  nave  obtained  ano  not  pur¬ 
sue  tne  development  further,  instead  we  will  take  the  opportunity  to  consider  two  ways 
of  increasing  the  efficiency  of  the  loops  in  an  existing  algorithm.  i 

One  way  to  improve  tne  efficiency  of  an  existing  loop  is  to  look  for  a  way  to 
Change  tne  guard  of  tne  loop  so  that  fewer  iterations  are  needed  to  achieve  tne  same 
goal.  A  knowledge  of  number  theory,  common  sense,  or  a  careful  analysis  of  tne 
problem  would  tell  us  that  when  the  quotient  (ie  z  div  p)  is  less  than  tne  current  prime 
p  mere  can  be  no  other  prime  factors.  Applying  this  criterion  will  allow  us  to  stop  the 
outer  loop  earlier  than  is  possible  with  the  test  zi'p.  This  refinement  will  be  included 
in  our  final  implementation  of  the  algorithm. 

A  second  way  to  improve  the  efficiency  of  an  existing  loop  is  to  increase  its  aver¬ 
age  Iterative  strength.  This  will  have  the  consequence  of  on  average  oecreasing  the 
bound  function  by  larger  amounts  with  each  iteration.  The  iterative  strength  of  me 
outer  loop  in  our  example  is  tied  to  successive  primes  and  there  does  not  appear  to  be 
a  way  of  eliminating  any  of  the  primes  from  consideration.  Therefore  our  second  stra¬ 
tegy  IS  not  applicable  to  the  outer  loop.  However  this  idea  can  be  applied  to  the  inner 
loop.  To  understand  this  let  us  focus  back  on  our  ii-mechanism  where  if  the  onginal 
z«  was  a  prime  raised  to  a  large  power  teg  zo  =  irn  we  could  use  the  standard  binary 
doubling  strategy  for  exponentiation  which  is  logarithmic  in  the  exponent.  We  have  not 
bothered  to  include  the  second  refinement  in  our  final  algorithm.  We  will  however  in 
other  examples  use  this  second  strategy  for  improving  the  efficiency  of  existing  loops. 

Our  final  algorithm  takes  the  following  form. 

Ip  1  <  zO  — > 

Svr  z.p.irinteger  — » 

z  :=  zo,  p  :=  1,1  ;=  0; 

Srp 

p  :=  nextprime  (p); 

do  z  mod  p  =  0  — > 

i,  f[i+l],  z  ;=  1+1,  p.  z  div  p 

Od: 

Spr  — >  z  div  p  <  p; 

I  $pt  z  >  1  — >  I,  f[i+i]  :=  (+1,  z; 

'  Sr;  z  div  p  <  p  =>  f.  I 

P> 

Several  observations  can  be  made  about  this  implementation.  Firstly  a  repeat  ...until 
I  loop  has  been  used  m  preference  to  a  do-ioop  because  termination  could  not  be  pos- 

j  sible  until  at  least  one  prime  has  been  tried  as  a  factor  and  so  ft  is  most  appropriate  to 

test  tne  guard  at  me  end  of  the  loop.  Application  of  the  guaro  at  me  beginning  of  tne 
I  loop  in  this  case  requires  some  unnecessary  duplication  of  code.  As  is  usually  tne 

I  case  me  li-mechamsm  can  terminate  in  one  of  two  states.  These  termination  states 

I  must  be  accommodated  in  our  implementation. 

I  The  implementation  m  Pascal  of  a  prime  factorization  algorithm  aescribed  by 

I  Aiagic  and  Arbib  [  8  J  is  given  below. 
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Degin 

t  :=  o;  k  ;=  6; 

q  :=  n  div  d[6];  r  :=  n  mod  dtoi; 
while  (r  =  0)  or  q  >  d[k]  do 
begin 

if  r  =  e  then 
begin 

t  :=  t+1;  fit]  :=  dfkl; 
n  :=  q 
end 
else 

k  :=  k+1; 
q  :=  n  div  dlkj; 
r  ;=  n  mod  dikl 
eno: 

if  n  >  )  then 
begin 
t  :=  t+1; 
fit]  ;=  n 
end 
end 

in  comparing  the  two  implementations  we  see  that  by  using  a  TT-mecnanism  in  prefer' 
ence  to  an  alternative  construct  we  have  avoided  the  need  to  apply  the  factor  test  (le  r 
-  twice  m  succession.  We  would  also  suggest  mat  me  first  solution  is  simpler  ana  is 
the  ‘preferred  solution*  because  there  is  a  loop  over  all  possible  prime  factors  ano  a 
second  loop  overmuitipie  occurrences  of  a  given  prime  factor. 

As  a  final  observation  about  the  development  of  the  solution  using  mouctive 
refinement  although  me  author  was  aware  of  Alagic  and  Arbib's  solution  at  the  time, 
me  reasoning  described  here  is  a  fairly  faithful  transcription  of  how  the  final  solution 
was  arrived  at.  We  would  claim  that  inductive  refinement  gave  strong  constructive  gui¬ 
dance  and  turned  this  problem  into  a  relatively  trivial  one.  The  logical  development 
followed  by  Aiagic  and  Arbib  does  not  appear  to  be  quite  so  straightforward  at  least  to 
this  author. 

5.3.  Deductive  Initialization 

in  our  earlier  discussion  of  the  structure  of  loops  we  made  the  observation  mat 
for  nested  loops  me  rote  of  the  outer  loop  is  mat  of  applying  an  iterative  process  ana 
Its  accompanying  Initialization  steps  repeatedly.  We  have  in  the  preceding  two  sub¬ 
sections  examined  cases  where  the  iterative  processes  that  have  been  applied  repeat¬ 
edly  were  treated  uniformly  in  that  no  special  requirements  were  needed  for  tne  first 
application  of  me  iterative  process.  There  is  however  an  important  class  of  problems 
where  tne  requirements  for  the  first  application  of  an  iterative  process  differ  from  me 
requirements  of  subsequent  applications.  For  this  class  of  problems  me  first  applica¬ 
tion  of  the  Iterative  process  (or  iT-mechanism)  needs  to  assume  the  roie  of  an  initializ¬ 
ing  step  for  subsequent  applications  of  a  loop-body  that  incorporates  tne  IT- 
mecnanism.  The  dynamic  initialization  required  for  the  iT-mechanism  is  referred  to  as 
a  /^-mechanism,  its  structure  must  be  deduced  from  the  state  of  the  computation 
wnen  the  Ti-mechamsm  terminates  without  having  established  the  postcondition.  The 
roie  of  the  ^-mechanism  is  to  change  the  state  of  the  computation  to  a  configuration 
where,  if  the  postcondition  still  has  not  been  established,  it  is  possible  to  again  apply 
tne  ii-mechanism.  The  underlying  structure  of  the  loops  for  this  class  of  problems  is: 


rr-mecnanism;  (initializing  slept 

00  B|  — > 

a-mechanism: 

n-mecnanism 

00 

Traoitionally  prooiems  OiscusseO  in  the  literature  that  have  .these  initialization  require¬ 
ments  have  loop  bodies  that  effectively  apply  the  ff-mechanism  first  le 

00  B|  — > 

n-mechanism: 
if  2B0  — » ihnnechanism 
0  B|  — >  skip 
fi 

00 

Because  it  is  possible  for  me  H-mechanism  to  establish  the  postconoition  it  is 
essential  to  protect  the  A-mechanism  wim  an  extra  guarO.  This  amounts  to  loop  over- 
oesign.  We  wouiO  suggest  that  this  latter  implementation  is  inferior  because  it  applies 
unnecessary  tests  ano  also  because  it  violates  the  basic  iOea  that  each  loop  shouiO 
have  an  appropriate  initializing  step. 

At  this  point  we  are  ready  to  consider  several  classic  examples  that  belong  to  mis 
important  class  of  problems. 

Example  5.4  Partitioning  an  Array 

The  problem  of  partitioning  an  integer  array  a[1..no]  about  some  value  x  is  a  fam¬ 
iliar  problem  in  computing  science.  As  we  have  mentioned  it  is  a  prototype  for  a  class 
of  problems  mat  are  amenable  to  a  similar  memod  of  solution. 

Stating  the  partitioning  problem  a  little  more  precisely  the  task  at  hand  is  to  parti¬ 
tion  me  array  elements  about  x  such  that  ail  elements  less  than  or  equal  to  x  are  in 
one  partition  and  all  those  elements  greater  than  or  equal  to  x  are  In  the  other  parti¬ 
tion.  There  are  a  number  of  variations  on  this  basic  problem  which  depend  on  me  ori¬ 
gin  of  the  partitioning  value  x  and  whemer  or  not  it  is  present  in  the  array.  We  will 
concentrate  on  me  general  formulation  of  the  problem  where  no  assumptions  are 
made  about  x.  The  requirements  given  suggest  the  following  schematic  diagram  as  a 
possible  terminating  condition. 


1  1 

I 

nd 

X  — >  « — >.  X 


Where  all  a(1..i]  are  less  man  or  equal  to  x,  and  all  afj  .nb]  are  greater  man  or 
equal  to  x.  Of  course  it  is  possible  that  x  may  be  eimer  greater  than  the  largest  ele¬ 
ment  in  the  array  or  less  than  me  smallest  element  in  the  array,  it  is  desirable  mat 
our  formulation  handle  these  special  cases  smoothly  and  naturally.  Given  tnese 
requirements  we  may  propose  the  following  postcondition  as  suitable  for  use  in 
developing  the  partitioning  aigorimm. 

R;  (0 1 1 1  nd)  V  p  ((1  i  p  ^  I)  => 
lalpl  1 X))  n  1)  1  nd+1)  A  V  q 
((j  1  q  1  nd)  =>  (a[q]  >.  x))  a  i  =  |-1 


It  IS  interesting  to  note  mat  most  postconditions  given  m  the  literature  for  mis 
problem  are  formulated  in  such  a  way  that  i  and  j  are  allowed  to  "crossover"  (  2.4,12  J. 
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Crossover  seems  to  be  an  artefact  or  existing  implementations  rather  tnan  something 
that  IS  inherent  in  the  problem. 

Having  formulated  the  postcondition  we  can  now  proceed  with  the  development  of 
the  algorithm.  The  free  variables  associated  with  R  are  i  and  ).  The  ranges  for  these 
variables  are  already  supplied.  \Afe  have: 

i:  (b  i  I  ^  nd) 
j:  tliji.ne+1) 

From  these  ranges  we  are  free  to  cnoose  as  our  projection  values  i  =  e  and  j  =  ne-i-l. 
Substituting  these  values  for  i  and  j  into  the  postconditioh  R  yields  the  following  invari¬ 
ant  P  and  determinate  O: 

P:  (6  i.  i  i.  nd)  ^vp  d  ^  p  ^  i)  =>  lafpl  i  x)) 

^  I  i.  nd+1)  AVq  (j  i.  q  i.  nd)  => 

(a[q]  >.  X)) 

D:  1  =  1-1 

Because  tne  antecedents  of  the  two  implications  are  false  for  the  chosen  projection 
values  tne  two  implications  will  still  be  true.  The  determinate  is  only  true  at  projection 
for  nd  =  d  and  false  for  larger  values  of  nd. 

in  this  case  the  bound  function  can  be  taken  directly  from  the  determinate  i.e. 
t:  J  -  i  -  1  >.  d 

lA/e  might  at  this  stage  be  tempted  to  suggest  that  a  suitable  guard  would  be  either  i  < 
j-1  or  I  #  j-1.  As  we  will  see  a  little  later  this  suggestion  is  premature  because  we 
nave  not  taken  into  account  the  iterative  capacity  of  the  loop. 

Our  task  now  is  to  develop  the  loop  body.  Applying  the  inductive  refinement 
methodology  we  are  looking  in  the  first  instance  for  the  weakest  general  iterative 
mechanism  capable  of  establishing  the  postcondition  R.  To  establish  R  we  have  three 
options:  increasing  i,  decreasing  j,  and/or  changing  the  configuration  of  the  elements 
in  tne  array.  If  the  array  were  already  in  a  partitioned  configuration  then  the  problem 
would  reduce  to  one  of  establishing  the  appropriate  values  for  i  and  j  that  satisfied  tne 
determinate.  A  mecnanism  capable  of  establishing  the  determinate  under  these  con¬ 
ditions  can  be  considered  as  the  iT-mechanism  for  the  problem.  The  weakest  possible 
mechanism  would  be  one  that  changed  either  i  or  j  but  not  both.  However,  the  more 
general  mechanism  is  one  capable  of  establishing  R  for  atf  possible  final  i  and  j 
values.  That  is.  it  would  be  possible  for  some  data  configurations  to  establish  R  by 
Changing  just  two  variables,  i  and  j.  without  moving  any  elements  in  tne  array. 
Developing  the  iT-mechanism  in  itself  can  be  seen  as  a  separate  problem  which  could 
be  solved  by  applying  similar  methods,  instead,  having  identified  the  iT-mechanism. 
we  will  go  straight  to  its  implementation  as  it  is  very  straightforward.  In  essence  all  we 
need  is  a  mechanism  to  confirm  the  following  configuration  for  all  allowable  i.  and  j. 


'  I 


f - <  X — - i  X - ? 

In  trying  to  confirm  R,  the  mechanism  we  propose  must  maintain  tne  invariant  P. 
Should,  however,  the  iT-mechanism  enter  a  state  where  it  is  not  possible  to  make 
further  progress  without  changing  other  variables  (ie  changing  the  array  configuration) 
tne  n-mechamsm  must  terminate  and  some  other  action  must  be  taken.  Our  tl- 
mecnanism  to  handle  all  possible  partitioned  configurations  can  take  the  form 


n-mechaniam: 


il  :*  j-1; 
ao  i  <  il  — » 

if  a(i+11  ^  X  — >  I  :=  i+1 
Q  a[i+l]  >  X  — »  il  ;=  I 
fi 
od: 

jl  :=  i+1; 
do  jl  <  i  — > 

if  a[j-1]  >.  X  — >  j  ;=  j-1 
0  aIj-11  <  X  — » jl  ;=  j 
fi 

od 

Whenever  tne  n-mecnanism  terminates  it  can  be  in  one  of  two  states,  either  R  will 
have  been  cohfirmed  or  the  computation  will  be  in  what  we  shall  call  a  Estate  ana  R 
will  still  hot  have  been  established.  A  A-state  is  characterized  by  the  conjunction  of 
tne  conditions  that  bring  about  early  termination  of  the  ii-mechanism  i.e.  in  this  case 

Estate:  ati+1]  >  x  a  alj-ll  <  x 

This  state  reflects  the  detection  of  two  wrongly  partitioned  elements.  To  make  pro¬ 
gress  under  the  invariance  of  P  the  complements  of  both  the  conjuncts  in  the  A-state 
must  be  established.  That  is.  we  require 

/  a(i+ll  i,x  Aatj-11  >,  X 

A  swap  of  the  elements  a(i+1]  and  a(j-1)  will  achieve  this.  It  will  also  set  up  a  condition 
that  will  allow  i  to  increase  by  one.  and  j  to  decrease  by  one  under  the  invariance  ot  P. 
The  A-mechanism  can  therefore  take  the  form: 

A-mechanlsm: 

i.  j,  a(i+l],  a(j-l]  :=  i+1.  j-1,  alj-1],  a(i+11 

After  application  of  the  A-mechanism  the  computation  will  again  be  in  a  state  where  it 
IS  possible  to  apply  the  TT-mechanism  in  an  effort  to  confirm  the  postconditioh  R.  The 
loop  to  establish  the  determinate  will  therefore  consist  of  alternatively  applying  tne  ii- 
mecnanism  and  the  A-mechanism. 

The  seemingly  obvious  way  to  combine  these  two  components  of  tne  loop  body  is 
as  follows. 


do  B  — > 

n-mecnanism; 

A-mechaniam 

Od 

unfortunately  this  method  of  composition  for  the  two  mechanisms  turns  out  to  oe 
unsatisfactory  in  this  case  for  the  fundamental  reason  explained  in  the  introduction  to 
this  subsection.  We  are  therefore  led  to  the  idea  of  applying  the  ii-mechanism  at  ini¬ 
tialization  and  then  constructing  a  loop  body  with  the  A-mechanism  at  initialization 
and  then  constructing  a  loop  body  with  the  A-mechanism  preceding  tne  il- 
mecnanism. 

The  only  task  that  remains  is  to  determine  the  guard  for  the  loop.  To  do  this  we 
must  first  determine  the  iterative  capacity  of  the  loop  body.  The  loop  body  has  the 
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following  structure: 

00  ?  — > 

i. ).  ali+U.  a(j-1]  :=  i+1.  j-l.  aCj-lJ.  aIi+11; 
ii-mechanism 

00 

The  smallest  general  problem  requiring  iterative  soiution  by  the  loop  booy  will  be  a 
problem  where  ne  »  2  anO  a(i-t-1]  >  x  anO  aCj~1]  <  x.  For  this  problem  the  IT-mechanism 
applieo  externally  will  make  no  progress,  the  loop  will  then  be  entereo.  ano  the  swap 
will  be  maoe  together  with  the  accompanying  changes  to  i  ano  j.  The  Tl-mechanism 
will  then  again  be  encountereO  but  will  make  no  further  progress  as  R  will  have  been 
estabiisheO.  The  maximum  iterative  capacity  of  the  loop  is  only  2.  it  is  oeriveo  from 
me  two  statements  i  :=  !•»■]  ano  j  :=  j-1  in  the  A-mechanism  which  oecrease  me  bouno 
function  by  2.  We  can  now  proceeo  with  the  oetermination  of  the  guaro  noting  that  me 
bouno  function  was  oetermineo  earlier. 

t:  j-i-1  i  e 

lilmax:  2 

B:  t  >.  Umax 

B;  j-i-1  >.  2  •  i+3  i  j  ■  i  <  1-2 

The  full  impiementation  for  the  partitioning  mechanism  can  now  be  oescribeo. 

ipO^ne— » 

$vr  i.  j.  11.  ji.inieger  — > 

I :»  e,  j :»  ne+1: 

$00  i  <  j-2  — > 

i,  j.  a(i+1].  a[j-ll  :*  i+1.  j-l.  aQ-ll.  all+11; 

Si:  il  :=  |-1: 

00  i  <  il  — » 

if  aIi+1]  ^  X  — >  i  :=  1+1 
0  all+lJ  >  X  — »  il  :=  i 
fi 

oo: 

jl  :=  1+1; 

00  jl  <  J  — » 

if  a[j-11  >.  X  — >  J  :=  j-l 
Qalj-I]  <x— »jl  :*  j 
fi 

00 

$00: 

$r:  (i  =  j-1)  =>  I.  J.  a 
pi 

Several  comments  can  be  maOe  about  this  mechanism.  Referring  back  to  our 
original  structure  for  nesteO  loops  we  see  mat  me  TT-mechanism  occurs  in  me  algo¬ 
rithm  text  in  two  places,  first  as  an  initializing  step  for  me  outer  loop,  ano  seconOly  as 
part  of  the  boOy  of  the  outer  loop.  We  couiO  have  gone  right  aheao  ano  written  in  me 
rr-mecnanism  text  in  the  two  places  where  it  is  neeOeO.  insteaO  we  have  cnosen  to 
use  me  following  $i:  state  convention: 

This  convention  is  taken  to  mean  that  loops  with  a  oefineo  $i:  state  begin  execution  at 
mat  point  in  me  program  text.  There  are  a  number  of  omer  ways  we  couio  nave 
resoiveo  this  problem  inciuOing  the  use  of  me  structure  employee  by  Knum  that 
possesses  a  miooie  exit  (  15  ].  We  couiO  also  have  impiementeo  the  ii-mecnanism  as 


'  > 
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a  proceaure  and  made  two  procedure  calls,  one  at  initialization  and  one  in  tne  loop 
body.  Unfortunately  language  designers  nave  failed  to  recognize  this  fundamental 
control  structure  and  the  problem  of  needing  to  write  the  text  of  tne  Ti-mecnanism 
twice.  Wirtn  (  16  ]  discusses  sucn  problems  as  loops  with  ‘an  exit  in  tne  middle*,  and 
tnen  goes  on  to  consider  two  examples  which  he  considers  demonstrate  tnat  there  is 
no  ‘real  necessity*  for  such  loop  structures.  We  would  suggest  to  the  contrary  as  our 
partitioning  example  demonstrates  there  are  many  problems  that  can  best  be  solved 
using  tne  loop  construction  we  have  suggested. 

It  is  interesbng  to  compare  the  present  implementation  with  that  for  a  variation  on 
tne  same  problem  that  was  implemented  by  applying  Oijkstra's  methodology  [  4  ].  The 
important  different  lies  in  the  fact  that  the  {T-mechanism  is  iterative  rather  man  con¬ 
sisting  of  a  set  of  components  of  an  alternative  construct,  i.e. 

if  aOl  i.  X  — »  i  :*  i+1 
0  atj]  >  X  — »  j  :=  j-1 

0  a(j]  i.  X  <  a(i]  — >  swap  (a(i].  Wj]);  i  :=  i+1.  j  :=  j-1 
fi 

For  the  most  general  problem  the  difference  in  structure  maxes  very  little  differ¬ 
ence.  however  if  X  IS  present  in  the  array  (as  for  the  partitioning  mechanism  in  quicx- 
sort  (  2  ])  then  an  iterative  Ti-mechanism  is  more  efficient  because  its  greater  iterative 
strength  will,  on  average,  reduce  me  number  of  times  the  loop  guard  is  applied. 

We  would  suggest  mat  the  preferred  solution  for  partitioning  involves  an  iterative  ii- 
mechanism  rather  than  a  alternative  constru(^.  The  modifications  to  our  partitioning 
mechanism  most  appropriate  for  application  wim  quicksort  are  discussed  elsewhere  ( 

13]. 

As  a  point  of  programming  style  it  is  interesting  to  note  me  difference  between 
tne  present  solutions  and  the  OiiXstra-styie  solubons  for  the  partitioning  problem  and 
tne  inventory  report  problem.  In  bom  instances  our  memodoiogy  has  led  to  iterative 
iT-mechanisms  whereas  the  Oijkstra-styie  solutions  have  employed  alternative  con¬ 
structs. 

Example  5.5  A  Text  Formatting  Problem 

The  text  formatting  problem  that  we  wish  to  consider  involves  input  of  data  con¬ 
sisting  of  one  or  more  words  separated  by  one  or  more  spaces.  No  spaces  precede 
tne  first  word  but  there  may  be  spaces  trailing  me  last  word.  We  will  assume  for  sim¬ 
plicity  that  this  data  is  stored  as  an  array  of  n  characters.  The  requirements  for  tne 
formatted  output  are  tnat  successive  words  should  be  separated  by  a  single  space, 
and  mere  should  be  no  leading  or  trailing  spaces.  Essentially  the  same  problem  is 
discussed  m  detail  by  OijXstra  [  14  j.  We  have,  however,  generalized  it  so  tnat  the  data 
does  not  contain  a  sentinel.  The  other  issues  raised  by  Oijkstra's  specification  of  tne 
problem  are  peripheral. 

To  develop  a  solution  to  this  problem  using  inductive  refinement  in  the  first 
instance  we  are  looking  tor  tne  weakest  general  iterative  mechanism  capable  of  estab¬ 
lishing  the  postcondition  (i.e.  the  output  format  specified).  Assuming  there  are  neither 
leading  blanks  nor  is  there  an  array  of  only  blanks  then  we  might  propose  as  tne 
weakest  iterative  mechanism  a  procedure  mat  ‘reads*  a  single  word  and  writes  it  out. 
For  this  purpose  we  may  propose  the  following  mechanism.  (We  nave  cnosen  not  to 
specify  the  procedure  for  writing  out  a  single  word  explicitly.) 


! 
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n  :=  n«.  j  :=  4.  i  ;*  4.  space  ;=  ' 

00  I  <  n  — •> 

if  ati+1]  *  space  — »  i.  j.  w{j+ll  :=  i+l.  |+1.  a(i+ll 
Q  a[i+l]  =  space  — >  n  :=  i 
fi 

00 : 

writeworO  (w.p 

This  mechanism  will  certainly  hanoie  a  single  worO.  out  referring  pack  to  our  specifi¬ 
cations.  we  see  that  the  smallest  general  problem  may  inciuoe  zero  or  more  trailing 
spaces.  Our  more  general  ii-mechanism  shoulO  accommoOate  trailing  spaces.  The 
following  steps  will  therefore  neeo  to  be  aooeo  to  the  mechanism  oescribeo  above. 

n  :=  no; 

00  i  <  n  — > 

if  aIi+11  =  space  — >  i  :=  i+l 
D  afi+l]  *  space  — >  n  :=  i 
fi 

00 

We  now  nave  a  mechanism  to  hanOle  a  single  worO  in  the  general  case. 

Our  next  step  is  to  look  for  a  way  to  generalize  it  so  that  it  can  hanoie  more  tnan 
one  woro.  The  important  thing  in  Oealing  with  multiple  woros  is  that  they  all  must  oe 
separatee  by  single  spaces,  it  follows  that  we  must  incorporate  the  ‘writing  of  a  single 
space‘  into  our  mechanism.  Clearly  the  first  word  can  be  written  unconoitionaily.  A// 
remaining  woros  can  only  be  written  after  a  space  has  been  written,  it  follows  that  tne 
ii-mecnanism  should  be  applied  as  the  initializing  step.  The  basic  loop  structure  will 
therefore  oe 

n-mecnanism; 

00  I  <  n  — > 
write  (space); 

Ti-mecrtamsm 


The  detailed  implementation  is  as  follows: 
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Ip  6  i.  nd  — > 

$c:space:cnar  — >  space  :=  ' 
$vri.j.n.w[1..ne]:integer  — » 

I  :=  e: 


Wo  i  <  no  — > 
write  (space): 

$i:  n  :=  nO.  j  ;=o; 

do  I  <  n  — > 

i(  ati+11  *  space  — » i,  j.  w(j+ll  :=  i+1,  j+t.  a(i+U 
Q  aIi+11  =  space  — »  n  ;=  i 
fi 

oo: 

writewordCw.p : 
n  ;s  no: 


do  I  <  n  — > 

if  a(i+ll  =  space  — >  i i+1 
Q  aIi+1]  ^  space  — »  n  :=  i 
fi 

od 

$od: 

»r:  I  =  no  «>  true 
pi 


According  to  our  previously  stated  convention,  because  the  loop  has  a  $i:  state  its 
execution  will  begin  in  this  state.  This  will  avoid  the  need  to  write  the  text  of  the  1T- 
mechanism  twice,  once  at  initialization  and  a  second  time  in  the  body  of  the  loop. 

it  (s  interesting  to  examine  the  details  of  the  solution  we  have  presented  both  with 
respect  to  “input*  and  output  (input  here  refers  to  array  accessing  rather  than  a  file 
read).  With  respect  to  input,  initially,  and  with  each  successive  iteration,  a  new  word  is 
‘read*  together  with  any  trailing  spaces,  e.g.  ^2  ^3  ?4 

input:  (this  I  text  I  seems  I  short  I 


In  contrast  with  respect  to  output  we  have  w.,  w.  w. 

■  1.2  j  3  4 

!  Output:  |this|  text!  seems!  short! 

r 

[  It  IS  also  useful  to  maKe  a  comparison  with  the  input  and  output  sequences  for 

I  Oijkstra's  algorithm  (  14  ]  given  below. 


I/O  sequences  tOr  Oilkstra's  Algorithm 
input; 

Output; 


^2  ^3 

tIext  s|eems 


SjHORT 


'll  W2  W3  W4 

ItHIS  ItEXT  IsEEMS  isHORTl 


With  respect  to  input  for  Oijkstra's  algorithm  the  fact  that  the  first  character  of  the  next 
word  must  be  read  with  each  iteration  is  due  to  the  input  primitives  chosen.  We  would 
suggest  that  as  a  principle  of  programming  style  it  is  better  to  “peak-ahead*  as  this 
allows  us  to  maintain  a  more  meaningful  invariant,  in  our  algorithm  a  single  word  with 
trailing  spaces  is  “read*  with  each  iteration  whereas  with  Oijkstra's  implementation  tne 


R 
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second  ana  suosequent  characters  of  the  current  wora  are  read  together  with  any 
trailing  spaces  and  the  first  character  of  the  next  word  if  there  is  one.  Note  that  the 
Situation  IS  analogous  to  that  for  the  unordered  linear  search  discussed  earlier. 

For  the  output  of  our  algorithm  with  each  iteration  a  new  word  preceded  oy  space 
is  written.  With  Oijkstra's  algorithm  for  each  iteration  a  new  word  is  written  out  together 
with  a  trailing  space  if  it  is  estabiished  that  there  is  still  another  word  to  be  processed. 
We  would  suggest  that  the  output  invariant  maintained  by  the  former  implementation  is 
to  be  preferred  because  the  structure  of  the  algorithm  is  such  that  a  space  is  written 
unconditionally  with  each  iteration  of  the  outermost  loop,  it  might  be  added  that  Oijks- 
tra  has  employed  the  same  loop  control  structure  as  that  traditionally  employed  for  me 
partitioning  problem  discussed  earlier  with  the  consequence  that  extra  testing  must  be 
employed  in  the  body  of  the  loop. 

As  it  stands,  our  algorithm  for  the  text  formatting  problem  has  two  built-in  ineffi¬ 
ciencies  that  may  be  unacceptable  to  some  when  implemented  in  a  deterministic 
language  like  Pascal.  Fortunately  these  two  inefficiencies  can  oe  easily  eliminated 
without  Changing  the  basic  structure  of  the  algorithm. 

The  first  inefficiency  occurs  in  the  first  internal  loop  that  has  the  job  of  accessing 
the  characters  in  a  word  until  a  terminator  Is  encountered.  Whenever  this  loop  ter¬ 
minates  with  ‘a[i-«-1]  =  space*  true,  it  follows  that  i  can  be  incremented  by  one  before 
applying  me  second  Internal  loop  whose  job  it  is  to  read  trailing  spaces. 

The  second  inefficiency  occurs  wim  the  second  loop  whenever  it  terminates  with  afi-i-ll 
*  space  true.  This  implies  that  the  first  character  of  the  next  word  has  been  encoun¬ 
tered.  This  can  and  should  be  accommodated  when  me  next  iteration  is  made.  This 
latter  refinement  can  most  easily  be  incorporated  by  first  applying  a  mechanism  mat 
strips  off  any  leading  spaces  preceding  the  first  word.  Such  ah  action  sets  up  condi¬ 
tions  that  best  allow  us  to  apply  the  second  refinement.  These  steps  are  left  as  an 
exercise  to  the  reader. 

Example  5.6  Text  Scanning 

Knuth  in  his  structured  programming  discussion  [ref.  75  p  271]  cites  an  interest¬ 
ing  text  processing  problem.  Basically  the  problem  requires  me  processing  of  a 
stream  of  text  where  we  want  to  read  and  print  the  next  character  from  the  input.  If  a 
single  7'  (slash)  is  encountered  we  need  to  advance  to  me  next  tab-stop  position. 
However,  if  two  consecutive  slashes  ’//*  are  encountered  the  output  should  be 
advanced  to  the  beginning  of  the  next  line.  After  printing  a  period  *.’  an  additional 
space  Should  be  inserted  in  the  output 

TheTT-mechanism  in  this  case  will  simply  be  one  that  reads  and  writes  one  char¬ 
acter  at  a  time  provided  no  slash  has  been  encountered.  After  including  the  refine¬ 
ment  that  a  ‘space*  must  be  writteh  after  a  period  we  may  propose  me  following  iT- 
mecnanism: 

I .-  eof.  n  .-  nO; 

do  itf  n  — > 

read(x);  i eof; 

if  x  ^  7‘  — »  writeCx):  if  x  =  ->  writer  ')  fi 

0  x  *  7'  — »  n  ;=  i 
fi 

00 

What  remains  is  to  generalize  this  mechanism  so  that  it  acts  appropriately  when  me 
7T-mecnanism  experiences  forced  termination,  it  is  apparent  that  a  A-mechanism  is 
required.  What  the  A-mechanism  must  accomplish,  having  encountered  one  /'  is  to 
distinguish  whemer  a  tab  or  a  newline  should  follow  in  the  output.  The  A-mecnanism 


may  therefore  take  the  form: 
read(x): 

if  X5<  7'  -->  write(taO);  writetx);  if  x  =  ->  writef'  ')  fi 

Q  X  =  7'  — >  writein 
fi 

We  see  that  the  oasic  structure  of  this  algorithm  follows  the  same  uhoeriying  pattern 
as  me  previous  example.  We  may  therefore  write  the  final  implementation  in  the  fol¬ 
lowing  way. 

Ip  true  — > 

$vn.n.hO:boolean:  x:char  — > 
nO  :=  true; 

$00  I  ^  no  — > 
reaOOc); 

if  x  #  7'  — >  write(tab);  writefx);  if  x  =  ->  wrlte('  ')  fi 

0  X  =  7'  — >  writein 

fi; 

Si:  I  ;=  eof.  n  :=  nO; 

00  I  ^  n  — > 

reaooo;  i  :=  eof; 

if  X  *  7'  — >  writetx);  if  x  =  ->  writeC  ')  fi 

Q  X  =  7'  — >  n  :=  i 
fi 

00 
$00 ; 

$r:  I  =  no  =>  true 
pi 

in  this  implementation  we  have  borrowed  Pascal's  I/O  facilities. 

It  IS  difficult  to  maxe  an  absolute  comparison  of  this  mechanism  with  Knuth  s 
implementation  as  at  face  value  he  does  not  take  into  account  the  possibility  of 
encountering  an  end-of-file.  The  present  construction  avoids  the  problems  encoun¬ 
tered  by  Knuth  wnen  slashes  (e  g.  one  or  two  consecutive  slashes)  are  met  in  the  input 
stream.  The  iterative  iT-mechanism,  by  simply  reading  and  writing  characters  until 
either  the  input  is  exhausted  or  a  slash  is  encountered,  resolves  the  problem  with  the 
slashes  in  a  more  straightforward  manner.  We  would  suggest  that  present  mechanism 
IS  Cleaner  and  conceptually  simpler  than  Knuth's  implementation.  Knutn  argues 
against  the  idea  of  duplicating  the  code  associated  with  the  period.  This  can  easily  be 
avoided  m  our  implementation  too  by  making  use  of  Pascal's  buffered  input  facilities. 
There  IS,  however,  no  significant  gam  to  be  made  by  pursuing  such  an  alternative.  We 
do  not  accept  Knutn  s  argument  tnat  duplication  of  code  is  a  ‘waste  of  energy". 
Metnodoiogicaiiy  we  suggest  tnat  the  /^-mechanism's  role  is  also  to  make  progress 
towards  termination  Hence  the  underlying  structure  of  our  mechanism. 

Example  ftJ  Exponentiation 

The  problem  of  computing  z  =  a*^  where  a  >  o  and  the  integer  p  >.  e  is  a  weii- 
Known  problem.  We  will  discuss  it  briefly  because  it  raises  several  fundamental  issues 
about  the  structure  of  loops  and  programming  style.  Choosing  first  a  well-formed 
postcondition  (which  is  not  simply  z  =  a®)  and  then  projecting  the  invariant  we  get 


P;  ©  1  y  A  z  *  =  a 

in  attempting  to  solve  tnis  problem  we  will  neeo  to  cnange  at  least  two  variables  m 
oraer  to  maintain  the  tnvariant.  The  most  or  obvious  choice  is  to  cnange  z  ana  y  while 
maintaining  the  invariant.  This  leads  directly  to  the  simple  method  for  exponentiation 
mat  IS  a  linear  function  of  exponent. 

The  other  alternative,  which  turns  out  to  be  more  interesting,  is  to  instead  change 
me  pair  of  variables  x,  and  y  while  maintaining  the  invariant.  Under  these  conditions, 
admitting  the  operations  of  multiplication  and  division,  the  weakest  iterative  mechan¬ 
ism  mat  can  establish  the  postcondition  will  be  one  that  deals  with  me  case  where  b  is 
a  power  of  two.  With  the  projection  values  x  =  a,  y  =  b  and  z  =  1  me  ii-mechanism  can 
therefore  take  the  form; 

do  eventyj  — > 

y  :=  y  div  2,  x  ;=  x  “  x 
od 

This  mecnanism  terminates  with  y  odd  and  greater  than  or  equal  to  one.  if  y  has  been 
reduced  to  one  mere  is  no  need  for  further  iteration  and  so  the  iterative  mechanism 
can  terminate,  in  the  other  case,  where  y  is  odd  and  greater  than  one  it  is  necessary 
to  derive  me  associated  A-mechanism  that  will  shift  me  computation  to  a  state  wnere 
it  IS  again  possible  to  apply  me  ii-mechanism.  Taking  these  steps  through  in  a  similar 
manner  to  mat  applied  for  previous  examples  we  are  led  to  the  following  implementa¬ 
tion. 

Ip  ©  <  a  *  ©  1  b  — > 

»vrx.y,z:integer  — > 
x  :=  a,  y  :=  b.  z  :=  1 ; 

♦do  1  <  y  — > 

y  :=  y-1.  z  ;=  z  *  x; 

♦i:  do  eventyj  — 

y  :=  y  div  2,  x  ;=  x  *  x 

Od 

♦od: 

♦r:  y  =  1  =>  z  ;=  z  *  x.  y  =  ©  =>  z 
P< 

With  this  implementation,  once  y  has  been  reduced  to  1.  there  is  no  need  tor  turtner 
Iteration.  At  this  point  we  might  be  satisfied  with  the  development  given  as  it  fits  natur¬ 
ally  into  the  same  framework  as  the  previous  two  algorithms  which  possess  deductive 
dynamic  initialization  states  it  is.  however,  useful  to  make  comparisons  with  two  omer 
implementations,  one  given  oy  OijKstra  (  3  .  p  66).  and  a  second  given  by  Ones  [  4  . 
p.240] 

Dijkstra  s  implementation  nas  the  form 

x.y.z  :=  a.D.i. 
do  y  #  ©  - ' 
do  evenly)  -■> 

X.  y  -  X  '  X  y  Oiv  2 


This  implementation  is  essentially  the  same  as  ours  except  that  the  order  ot  the  ii- 
mechahism  ana  the  other  mechanism  in  the  Dody  of  the  loop  has  oeen  reversed. 
OijKstra  suggests  that  the  example  above  leads  him  to  the  conciusioh  that  ‘support  is 
weak'  tor  the  need  to  have  loops  with  "intermediate  exits’. 

\/Ve  would  argue  that  our  implementation  is  to  be  preferred  because  it  recognizes  that 
the  iT-mechanism  alone  can  take  the  computation  through  to  a  state  where  it  is  possi¬ 
ble  to  establish  the  postcondition  (i.e.  by  z  :=  z  x)  without  further  contribution  from  the 
body  of  the  loop.  In  contrast  Oijkstra's  implementation  is  always  committed  to  apply 
tne  complete  A-mechanism  once  the  loop  is  entered.  A  further  difference  is  that  in 
our  algorithm  y  is  maintained  as  either  even  or  odd  whereas  in  Oijkstra's  implementa¬ 
tion  it  IS  reduced  to  zero  which  is  not  considered  in  mathematics  at  least  to  be  an  even 
number.  Hence  the  loop  does  not  maintain  as  an  invariant  property  that  y  remains 
either  even  or  odd.  These  distinctions  may  be  too  subtle  for  some  but  taken  in  con¬ 
junction  with  the  other  examples  that  require  deductive  initialization,  it  is  apparent  that 
there  Is  a  consistent  pattern  operating.  The  case  where  y  =  1  requires  a  test  for  eve- 
ness  with  Oijkstra's  implementation  which  is  naturally  avoided  by  our  implementation. 

A  comparison  with  Ones'  implementation  given  below  raises  another  issue: 
x.y.z  ;=  x.y,  1 ; 

do  0  <  y  ^  eventyi  — y.x  ;=  y  div  2.  x  *  x 
0  0  <  y  A  oddtyJ  — >  y.z  ;=  y-1,  z  *  x 
od 

Because  tne  tests  for  even  and  odd  are  incorporated  into  the  loop  guard  the  test  o  <  y 
must  be  applied  as  many  times  as  the  even  and  odd  tests.  Consequently,  the  test  o  <  y 
will,  on  average,  be  applied  considerably  more  times  than  is  necessary.  Our  imple¬ 
mentation,  with  its  n-mechanism,  avoids  this  problem. 

There  still  remains  an  inefficiency  in  our  implementation  that  has  oeen  over¬ 
looked.  The  inefficiency  arises  from  the  way  in  which  the  ii-mecnanism  ana  the  A- 
mecnanism  have  been  coupled  together.  Part  of  the  role  of  the  A-mecnanism  is  to 
Change  y  from  an  odd  value  to  an  even  value  so  that  the  iterative  ii-mechanism  can  oe 
re-applied,  it  follows  that  the  test  to  see  whether  or  not  y  is  even  is  not  needed  until 
attar  the  body  of  the  fi-mechamsm  loop  has  been  executed  at  least  once.  As  such, 
our  existing  loop  structure  will,  in  general,  make  more  applications  of  the  test  ‘eventyi* 
than  are  needed  to  solve  tne  problem.  The  following  program  structure  eliminates  tne 
redundant  "even(y)‘  testing. 

do  eventyj  —> 

y  ;=  y  div  2.  X  :=  X  *  X 
od; 

$do  1  <  y  — > 

y  ;=  y-1.  z  :=  z  *  x. 

rp 

y  :=  y  div  2,  x  x  *  x 
pr  — >  odd(y) 
sod; 

$r:  y  =  1  ^  z  .-  z  '  x.  y  =  ®  =>  z 
P' 

In  this  implementation,  we  describe  the  A-mechanism  and  the  n-mechanism  m  the 
body  of  the  loop  as  being  co-operatively  coupled.  The  price  we  have  had  to  pay  tor 
this  rationalization  of  the  mechanism  has  been  to  explicitly  include  tne  guarded  n- 
mecnanism  as  the  initializing  step  and  replace  the  guarded  n-mechanism  in  the  loop 
body  by  its  unguarded  form  (i.e.  a  repeat-ioopi  The  general  framework  for  tne  co- 


operative  coupling  refinement  is: 

guaraed  ii-mecnanism:  (initialization) 

$do  guard  — > 

A-mecnanism; 

unguarded  n-mecnanism 
$od 

This  refinement  can  oe  applied  equally  well  to  the  previous  two  algorithms  tnat 
involved  deductive  initialization  provided  the  mam  loop  guard  is  chosen  sucn  that  tne 
z\-mechanism  cannot  establish  the  postcondition  without  suosequent  application  of 
tne  subsequent  application  of  the  unguarded  iT-mechanism. 

It  should  be  noted  that  it  is  not  possible  to  apply  the  co-operative  coupling  refine¬ 
ment  to  implementations  where  the  ii-mechanism  precedes  the  /^-mechanism  in  tne 
body  of  the  loop.  Furthermore,  if  we  were  to  choose  tne  guard  of  the  mam  loop  sucn 
that  the  A-mecnamsm  m  the  loop  body  were  able  to  establish  the  postcondition  then  it 
would  not  oe  possible  to  employ  an  unguarded  ii-mechanism  m  the  loop  body,  in  our 
example  this  situation  wouid  arise  if  we  had  used  the  guard  *0  <  y*  instead  of  ‘1  <y*. 

We  will  m  the  next  section  see  other  problems  with  a  higher  degree  of  symmetry 
that  can  be  treated  according  to  essentially  the  same  principles. 

5.4.  Iterative  initialization 

There  is  an  important  class  of  loop  problem  that  follows  on  naturally  from  the  dis¬ 
cussion  in  the  preceding  section.  These  are  a  set  of  problems,  which,  on  tne  surface 
at  least,  appear  to  possess  a  measure  of  symmetry.  They  are  often  characterized  by 
possessing  more  than  one  variable  or  collection  of  data  to  which  it  would  appear  tnat 
essentially  the  same  mechanism  could  be  applied  in  sequence.  Probably  the  best  way 
to  introduce  the  issues  raised  by  this  class  of  problems  is  by  way  of  example.  We  will 
now  pursue  this  course. 

Example  5.8  The  Greatest  Common  Divisor  Problem 

The  greatest  common  divisor  probier  >  should  perhaps  by  now  have  been 
relegated  to  a  position  beyond  discussion.  '.Ve  will  attempt  to  present  a  different  per¬ 
spective  on  the  development,  interpretation,  and  implementation  of  solutions  to  tne 
problem  in  the  light  of  the  proposed  methodology. 

We  may  assume  that  we  are  given  two  positive  integers,  a  and  b.  and  we  are 
required  to  establish  the  postcondition: 

R:  x  =  y  =  gcdCx.y)  ^  gcdCx.y)  =  gcd(a.b)  ''x>0Ay>e 

The  ranges  for  the  variabies  x  and  y  are 

x;  I  i,  X  1  a 
y:  1  1  y  1  0 

as  a.  and  b  must  at  least  share  the  divisor  1.  We  are  free  to  choose  as  our  projection 
values  X  s  a  and  y  =  b  from  which  we  are  led  to  the  foliowing  invariant  and  determinate: 

P:  gcdCx.y)  =  gcdCa.b)  ''  x  >  0  y  >  d 
D:  X  =  y  =  gcdCx.y) 

In  formulating  our  solution  to  this  problem  in  the  first  instance  we  are  looking  lor  me 
weakest  general  iterative  mechanism  capable  of  establishing  the  postcondition.  There 
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are  two  variables  associated  with  the  problem,  however,  in  the  tirst  instance  we  are 
looking  for  the  weakest  mechanism  so  we  need  to  investigate  whether  there  exists  a 
mechanism  that  possesses  the  followmg  characteristics  -  it  changes  only  one  variable 
While  maintaining  the  invariant  and  it  is  iterative  and  capable  of  establishing  the 
postcondition.  These  requirements  correspond  directly  to  the  situation  where  one  of 
the  variables  is  a  multiple  of  the  other.  The  corresponding  Ti-mechanism  might  there¬ 
fore  take  the  form 

do  X  >  y  — »  X  ;=  X  -  y  od 

This  mechanism  can  terminate  either  with  x  »  y.  confirming  that  y  is  a  multiple  of  x,  or 
with  X  less  than  y.  If  the  latter  case  prevails  further  processing  will  be  required.  At  this 
point  in  the  development  the  skeleton  structure  that  we  have  for.the  gcd  algorithm  is: 


^mechanism:  ??? 


dox>y- 
pr  — >  X  =  y; 


X  :=  X  -  y  od 


The  nature  of  the  dynamic  initialization  in  the  loop  body  for  the  Ti-mechanism  may  not 
be  immediately  apparent.  However,  its  role  is  by  definition  to  change  the  state  of  the 
computation  to  a  point  where  it  is  again  possible  to  attempt  to  apply  the  ir-mechanism 
again.  Examining  the  conditions  that  apply  after  termihation  of  the  TT-mechamsm.  it 
follows  that  X  must  be  less  than  y  if  further  processing  is  required  -  this  is  the  opposite 
Situation  to  that  which  the  Ti-mechanism  was  designed  to  handle.  As  x  has  been 
Changed  as  much  as  is  possible  we  might  expect  that  the  A-mechanism  win  need  to 
Change  y.  One  possibility  would  be  to  use 

y  :=  y  -  X 

This  mechanism  however  cannot  guarantee  to  change  the  state  of  the  computation  in 
one  iteration  to  a  situation  where  x  >.  y  and  it  is  again  appropriate  to  apply  the  n- 
mechanism.  The  obvious  choice  of  A-mechanism  is  therefore  one  which  has  a 
greater  iterative  strength  i.e. 

rp 

y  :=  y  -  X 
pr  — >  X  >.  y 

Our  complete  implementation  of  the  gcd  algorithm  can  therefore  take  the  form. 

Ip  0  <  a  A  0  <  b  — > 

Svrx.yiinteger  — > 

X  ;=  a,  y  ;=  b; 


£ 


I 


rp 

y  :=  y  -  X 
pr  — >  X  1  y; 

Si;  00  X  >  y  — > 

X  :=  X  -  y 
Od 

Spr  — ^  X  =  y 
Sr:  X  =  y  =>  X 
Pi 


i 

V 

■  ll 

I  [I 
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With  this  implementation  we  nave  deliberately  chosen  to  use  a  repeat  loop  for  the  A- 
mechanism.  because,  given  that  the  mechanism  always  starts  in  me  $i:  state,  to 
achieve  co-operative  coupling  between  the  two  loops  an  unguarded  A-mecnanism  is 
required.  This  repeat  loop/do  loop  structure  can  be  used  widely  for  aigortmms  wim  an 
Iterative  A-mecnanism. 

Several  comments  are  in  order  about  this  implementation  of  the  gcd  algorithm. 
As  a  reference  point  we  should  note  a  familiar  implementation  of  me  gcd  algorithm 
which  has  the  form 

X  :=  a.  y  :=  b; 
do  X  ^  y  — > 

ifx>y— >x;=x-y 
Dy>x— >y:=y-x 
fi 


The  advantage  of  our  algorithm  over  this  implementation  lies  in  the  fact  that  me  itera¬ 
tive  ii  and  A-mecnanisms  ensure  that  on  average  the  outer  loop  guard  for  our  algo¬ 
rithm  will  be  executed  significantly  fewer  times  than  the  guard  *x  *  y*.  We  would  there¬ 
fore  suggest  that  me  implementation  with  two  loops  in  the  loop  body  is  the  preferred 
solution.  Another  familiar  implementation  that  possesses  two  iterative  mechanisms  in 
me  loop  body  has  the  form: 

X  :=  a.  y  :=  b; 

do  X  ^  y  — > 

do  X  >  y  — >  X  :=  X  -  y  od; 
do  y  >  X  — >  y  :=  y  -  X  od 

Od 

In  this  implementation  the  two  inner  loops  are  not  co-operatively  coupled  with  conse¬ 
quence  that  the  test  'x  >  y*  is  applied  more  times  than  are  necessary  to  solve  me 
problem  i.e.  after  the  first  iteration  of  the  outer  loop  x  will  always  be  greater  man  y  if 
me  outer  loop  is  still  active.  This  inefficiency  cannot  be  overcome  by  changing  me 
first  inner  loop  (or  for  that  matter,  the  second)  to  a  repeat  loop,  in  fact,  it  would  seem 
mat  me  only  way  to  achieve  co-operative  coupling  and  hence  eliminate  me  ineffi¬ 
ciency  for  this  mechanism  is  to  admit  a  $i:  state  in  which  the  algorithm  begins  execu¬ 
tion. 

What  is  probably  most  interesting  about  this  algorithm  is  the  way  in  which  the 
proposed  methodology  led  us  directly  to  the  preferred  solution.  Furthermore,  even 
without  a  formal  specification  of  the  postcondition  in  searching  for  tne  weakest  iterative 
mechanism  we  would  be  led  down  me  same  path.  What  mis  example  underlines  is  me 
constructive  power  of  tne  methodology.  We  will  now  turn  to  anomer  example  which 
also  by  now  should  have  been  relegated  to  a  position  beyond  discussion. 

Example  5.9  Two-way  Merge 

The  two-way  merge  problem  is  more  usually  concerned  wim  files.  We  will,  how¬ 
ever.  phrase  the  problem  m  terms  of  arrays.  The  file  version,  if  needed,  can  easily  oe 
obtained  using  me  methods  suggested  m  section  4.  Our  concern  is  to  merge  two 
ordered  arrays  a(1..mo]  and  b[l..ne]  to  produce  a  third  array  c(1..me  +  nei.  Our  solu¬ 
tion  should  handle  all  cases  including  those  where  one  or  bom  of  the  input  arrays  are 
empty. 

At  this  point  we  could  write  down  formal  postconditions,  derive  invariants  and 
proceed  much  in  tne  same  way  as  for  most  of  our  other  examples.  We  nave,  however, 
chosen  to  proceed  more  informally,  partly  to  illustrate  that  the  memodoiogy  does  not 
necessarily  rely  heavily  on  the  more  formal  apparatus. 
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At  any  point  in  time  we  will  assume  that  a[1..i]  and  are  merged  to  give 
c[1..K].  where  k  =  i+j.  In  carrying  out  the  merge  the  possible  variables  for  change  are. 
i.  j.  k.  and  ctk-i-1].  the  first  three  of  which  would  be  initially  zero.  It  is  not  possible  to 
carry  out  a  merge  by  changing  either  one  or  two  of  tnese  variables.  Our  weakest 
iterative  mechanism  will  therefore  be  one  that  changes  at  least  three  of  these  vari¬ 
ables.  The  two  choices  are  either  i.  k.  and  c[k+1]  or  j,  k  and  clk+ll.  Selecting  tne  first 
cnoice.  tne  weakest  iterative  mechanism  that  could  reduce  the  problem  to  one  wnere 
no  further  merging  would  be  required  is  of  the  form: 

I  ;=  e.  J  :=  0.  m  :=  me; 

do  I  <  m  — > 

if  ati+l]  S  b[j+ll  — >  i.  k.  cfk+11  :=  i+l.  k+1,  aIi+11 
fl  an+1]  >  Wi+11  — »  m  .- i 
fi 

00 

This  mechanism  corresponds  to  that  situation  where  all  the  a(l..me]  occur  in  tne 
merged  output  before  the  first  element  in  the  b  array.  The  mechanism  is  designed  to 
terminate  as  soon  as  it  detects  other  than  the  assumed  most  favourable  situation  in 
accordance  with  the  standard  practice  we  have  adopted  for  constructing  iT- 
mecnanisms. 

We  need  to  understand  clearly  what  the  implications  are  of  the  n-mechanism  ter¬ 
minating  in  either  of  the  two  possible  states.  Whenever  the  ii-mechanism  terminates 
naturally  with  i  »  m  =  me  all  the  a(1..me]  will  have  been  merged.  Consequently,  tne 
problem  that  remains  is  not  a  merging  problem  but  rather  one  of  copying  the  remain¬ 
ing  elements  Dli+h.nP)  into  the  output  array  C.  The  implication  of  this  for  our  imple¬ 
mentation  IS  that  the  loop  controlling  the  complete  merging  process  should  terminate 
as  soon  as  it  is  detected  that  there  is  no  longer  a  defined  merging  problem  remaining. 
Forced  termination  of  the  TT-mechanism  in  its  other  state  (ie  with  i  <  mb)  suggests  that 
some  form  of  delta  mechanism  is  required.  Our  imntediate  suggestion  for  tne  A- 
mechanism  might  be: 

j,  k,  c(k+l]  :=  1+1,  k+1,  b(j+11 

However,  as  this  cannot  guarantee  to  place  the  computation  in  a  state  wnere  it  may  oe 
most  appropriate  to  apply  the  li-mechanism  a  better  suggestion  in  accordance  with 
cooperative  coupling  is: 

rp 

if  b(j+1J  J,  a[i+1I  — >  J.  k,  c[k+1J  :=  j+1.  k+1,  blj+1) 

0  btj+1]  >  ati+11  — >  n  :=  j 
fi 

pr  — » J  =  n 

Our  basic  structure  for  the  merging  component  of  the  problem  mig/tt  therefore  take 
tne  form: 
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rp 

it  btj+1]  S  a(i+l]  — >  j.k.cIk+11  :=  j+1,  k+1,  Wj+ll 
0  Wj+I]  >  a{i+l]  — >  n  :*  j 
fi 

pr  — >  j  =  n; 


00  I  <  m  — > 

if  a[i+l]  s  btj+U  — >  i.k.c(k+ll  :=  i+l.  k+1,  a[i+ll 
a  a(i+1]  >  b[j+ll  — >  m  ;=  i 
fi 

00 

00 

Tne  prootem  that  remains  with  the  merging  part  of  the  implementation  is  to  control  tne 
termination  of  tne  mechanism  when  the  problem  ceases  to  be  oefineo  as  a  merging 
problem.  It  IS  clear  that  either  of  the  internal  loops  has  tne  potential  to  terminate 
naturally  ano  hence  bring  about  a  state  of  the  computation  where  tne  problem  has 
been  reouceo  to  a  copying  problem.  For  example,  the  repeat-loop  can  terminate  witn 
J  =  n  =  ne  and  i  <  m  which  implies  that  a(i+1..m]  remains  to  be  copied,  in  this  situation 
tne  guard  on  the  do-ioop  that  follows  It  (i.e.  i  <  m)  is  not  sufficiant  to  prevent  the  sub¬ 
sequent  application  of  the  test 

if  a{i+11.<  bti+lJ... 

which  will  be  out  of  bounds  with  respect  to  the  b  array.  To  overcome  this  the  repeat- 
toop  mechanism  must  be  able  to  communicate  to  the  do-loop  (and  vice  versa)  that  a 
merging  problem  is  no  longer  defined. 

An  effective  way  to  accomplish  this  communication  is  as  follows: 

m  :=  me.  n  :=  j: 

»rp 

rp 

if  bIj+11  s  a(i+ll  -» j.k.clk+11  :=  j+1,  k+1.  b[|+ll 
0  blj+l]  >  a(i+lj  — »  n  :=  /.  m  ;=  me 
fi 

pr  — >  J  *  n; 


$i;  do  I  <  m  — » 

If  ali+lj  s  b(j+1]  — »  i,k.c(k+11  :=  i+l.  k+1.  ali+11 
Q  a(i+l]  >  blj+1]  — »  m  ;=  i.  n  :=  ne 
fi 

od 

»pr  -+ 1  =  n 

The  way  this  communication  mechanism  works  is  as  follows.  Each  merging  loop  uses 
a  switch  to  control  whether  its  successor  can  continue  to  execute.  Setting  n  =  j  initially 
effectively  ‘turns  off*  the  repeat-loop,  if  the  inner  do-ioop  terminates  naturally  then 
tne  merging  mechanism  terminates,  if.  however,  the  do-loop  is  subject  to  forcad  ter¬ 
mination  (i.e.  by  the  assignment  m  i.  indicating  that  an  element  from  tne  b-array 
should  be  merged  next)  then  the  repeat-loop  mechanism  is  ‘switched  on*  by  tne 
assignment  n  ne.  The  do-loop  mechanism  can  only  be  subsequently  switched  on 
by  the  repeat-loop  if  it  has  a  forced  termination  indicating  the  requirement  for  further 
merging.  And  so  the  two  iterative  components  that  carry  out  the  merging  are  alterna¬ 
tively  switched  on  and  off  in  each  case,  depending  on  how  their  predecessor  ter¬ 
minates.  This  control  structure  is  a  general  one  that  can  be  used  much  more  widely 


man  me  present  application.  A  repeat-loop  has  been  deliberately  used  for  me  outer¬ 
most  loop  because  it  will  allow  the  compiled  implementation  to  execute  fewer  steps  as 
me  mechanism  will  ‘fall  through*  when  the  guard  is  true. 

We  are  now  left  wim  the  task  of  implementing  the  copying  mechanism  mat  must 
follow  me  termination  of  the  actual  merge  part  of  the  process.  This  aspect  of  me 
implementation  is  straight  forward  and  so  we  are  led  directly  to  me  final  implementa¬ 
tion. 

Ip  1  i  me  V  a  ^  ne  — > 

$vr  i.j,k:integer:  cd.  me  +  nej:integer  — » 
i  :=  e.  j  :=  e.  k  ;*  0: 

Ip  1  ^  me  ‘  1  1  ne  — > 

$vr  m.n:integer  — > 
m  :=  me,  n  ;=  j; 

Srp 

.rp 

if  bl|+ll  s  afi+11  — » j,k,ctk+lj  :=  j+1.k+l.bg+ll 
Q  bIj+1]  >  a(i+l]  — »  n  ;=  j.  m  :=  me 
fi 

pr  — » J  =  n 
$i;  do  I  <  m  — > 

if  a(i+l]  1  btj+11  — >  i,k,cfk+lj  :=  i+l.k+l,a(i+ll 
0  ali+H  >  b(j+ll  — >  m  :=  I,  n  :*  ne 
fi 

od 

$pr  — » J  =  n 

»r:  (i  =  me  J  <  ne)  V  (i  <  me  A  j  =  ne)  i.j,k,c 

pi; 

do  I  <  me  — >  (,k,c(k+1J  ;=  i+l.  k+1,  a(k+ll  od; 
do  1  <  ne  — >  j,k,c(k+lj  ;=  j+1.  K+1,  blj+11  od; 

Sr:  I  =  me  A  j  =  ne  =»  k.c 

P» 

When  we  compare  this  implementation  of  the  two-way  merge  with  other  alterna¬ 
tives  It  IS  immediately  apparent  that  it  is  textuaily  more  complex.  We  may,  therefore, 
ask  what  is  me  justification  for  this  increased  textual  complexity?  The  justification  in 
part  comes  from  the  fact  that  me  implementation  is  mechanistically  simpler  than  other 
alternatives.  Consider,  for  example,  the  commonly  used  merging  construct: 

do  I  <  m  A  j  <  n  — > 

if  ati+1]  s  b[j+ll  — >  i,k.c(k+1]  :=  i+l,  k+1.  ali+l) 

0  afi+lj  >  bij+lj  — >  j,k,c(k+lj  ;=  j+1,  k+1,  blj+l) 
fi 

Od; 

‘copying  operations* 

For  this  implementation,  with  each  iteration  tests  on  both  i  <  m  and  j  <  m  must  be 
made,  in  our  implementation  only  one  of  these  tests  need  to  be  made.  The  ‘over¬ 
head’  in  our  implementation  caused  by  the  need  to  employ  forced  termination  and 
define  me  merging  operation  dynamically  should  in  general  be  offset  by  the  capacity 
to  use  simpler  mechanisms  to  merge  sequences  of  a  values  before  tne  current  b  value 
and  vice  versa. 


Oljkstra  (ref.  3  p.  126]  suog^sts  another  merging  mechanism  that  is  textuaiiy 
simpler  than  either  of  the  above  proposals.  The  basic  control  structure  for  this  imple¬ 
mentation  using  some  set  notation  is: 

x,y^  :=  X.Y.0; 

ooxvaoryso— * 

‘transfer  an  element  from  ix*y)  to  z* 

00 

Where  x+y  refers  to  a  union  of  two  sets  and  b  identifies  the  empty  set  Although  an 
attractive  implementation,  mechanistically  it  relies  on  the  use  of  sentinels  (which  is  not 
always  practical)  and  furthermore  it  does  not  degenerate  to  a  simpler  mechanism 
When  the  problem  reverts  to  a  copying  problem.  The  natural  structure  of  the  problem 
IS  therefore  hidden  by  the  mechanism. 

Of  course,  it  is  easy  enough  to  question  our  arguments  about  the  merging  prob¬ 
lem.  What  IS.  however,  much  more  important  is  to  recognize  the  underlying  charac¬ 
teristics  of  solutions  derived  by  always  seeking  and  building  solutions  to  problems 
around  the  weakest  iterative  mechanism  that  can  establish  the  postcondition.  We  win 
come  back  to  these  issues  in  the  section  on  classification  of  loop  constructs. 

One  final  comment  is  m  order  before  we  leave  our  discussion  of  the  merging 
algorithm.  Our  implementation  could  in  some  contexts  be  criticized  for  not  taking 
more  effective  action  wherv  either  of  the  internal  loops  experiences  forced  termination. 
For  example,  with  the  do-loop  when  ad-t-ll  >  b(j^1]  we  proceed  as  follows: 

0  a(i+i]  >  b(j+ll  — ♦  m  :=  i.  n  :=  nb 

However,  this  condition  invites  us  to  apply  a  merge  of  the  element  b(j+1]  i.e. 

Q  ali+U  >  blj+lJ  — >  m.n.i.k.c(k+l]  :=  i,nb.j+l.k+l.bQ+ll 

A  similar  strategy  could  be  applied  with  the  other  merging  loop  with  the  attendant 
structural  implication. 

Example  5.10  Binary  Tree  Searching 

To  complete  this  section  we  will  consider  two  more  examples  that  raise  certain 
issues  about  the  application  of  the  methodology  we  have  introduced. 

In  considering  the  binary  tree  search  for  comparison  we  will  focus  on  the 
representation  employed  by  Knuth  [  15  ].  The  binary  search  tree  is  represented  by 
three  arrays,  adl  denotes  the  information  stored  at  node  number  i.  and  l(i]  and  rd]  are 
the  respective  node  numbers  for  the  roots  of  that  node's  left  and  right  subtrees  with 
empty  subtrees  being  represented  by  zero.  If  we  pursue  the  idea  of  looking  for  the 
weakest  iterative  mechanism  we  are  quickly  led  to  the  following  implementation  with 
cooperative  coupling  and  a  deductive  iterative  initialization  scheme. 


Ip  •  1 1  — > 

$vr  p.n.n*:inteoer  — > 
p  :=  «.  n*  := 

$rp 

n  :=  no; 

rp 

if  a(i]  >  X  — >  p  ;=  i;  i  :=  l(il 
a  afil  ^  X  — ♦  n  :=  i 
pr  — >  I  =  n; 

$i;  n  ;=  n*: 

00  i  ^  n  — > 

if  a[i]  i  X  — >  p  ;=  i;  i  :=  rill 
0  all]  >  X  — »  n  :=  i 
fi 

oo 

$pr  — *  i  =  nO; 

$r;  i  =  no  =*  p 

P* 

Before  evaluation  our  first  solution  we  shall  present  a  textuaily  simpler  solution, 
the  essential  part  of  which  has  the  form: 

n  :*  o;  p  :*  n; 

00 Ilf  n  — > 

if  alii  1 X  — >  p  ;=  i;  i  :=  rill 
Q  ali]  >  X  — >  p  :=  i;  i  :=  l(i] 
fi 

00 

Comparing  the  two  solutions  we  see  that  the  fT-mechanism  has  essentially  tne  same 
loop  ano  guaro  structure  as  our  seconO  solution.  If  we  haO  in  fact  applied  tne  same 
type  of  refinement  as  finally  suggested  for  the  two  way  merge  we  would  have  ended  up 
with  the  following  ii-mechanism 

n  :=  ne: 

00  i  ^  n  — » 

if  all!  i.  X  — >  p  ;=  i;  i  ;=  rill 
Q  ali]  >  X  — ♦  n  :=  i;  p  ;=  i;  i  :=  llll 
fi 

00 

which  IS  just  our  second  solution  with  the  statement  n  ;=  i  inserted  to  bring  about 
forced  termination. 

Study  of  the  two  solutions  suggests  that  the  second  solution  is  to  be  preferred 
because  it  avoids  the  overhead  needed  to  bring  about  forced  termination  of  both  tne 
n-mechanism  and  the  /^-mechanism.  We  must  now  ask  what  are  the  implications  of 
this  most  recent  result,  it  would  seem  to  suggest  that  the  strategy  of  always  looking  for 
the  weakest  iterative  mechanism  that  can  establish  R  does  not  always  lead  us  to  tne 
preferred  implementation.  However,  all  is  not  lost.  The  situation  we  have  just  encoun¬ 
tered  IS  signalled  by  the  circumstance  where  the  guard  (or  its  compiemenu  for  tne 
outermost  loop  is  identical  to  the  guard  for  the  iterative  IT-mechanism.  in  sucn 
instances  we  should  evaluate  the  situation  to  decide  whether  or  not  it  is  appropriate  to 
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carry  out  tne  mechanical  transformation  neeoed  to  arrive  at  tne  second  preferreo 
solution  to  tne  problem. 

At  this  point  in  the  discussion  it  is  convenient  to  introduce  a  little  terminology  mat 
will  make  it  easier  to  usefully  evaluate  the  phenomena  we  nave  just  encountered.  Mfe 
say  that  iterative  alack  exists  in  an  implementation  when  it  is  possible  to  introduce  one 
or  more  iterative  constructs  into  the  mechanism  mat  will  on  average  reduce  tne  overall 
loop-guard-testing  required  by  tne  implementation.  This  concept  makes  way  for 
transformations  that  may  allow  on  the  one  hand  a  speed-up  of  existing  implementa¬ 
tions  while  at  tne  same  time  helping  us  to  design  iteratively  tight  implementations  in 
tne  first  instance.  An  implementation  is  said  to  be  iteratively  tight  if  it  is  not  possible  to 
introduce  an  iterative  mechanism  mat  will  reduce  tne  overall  guard  testing  required  by 
tne  aigorimm.  What  we  suggest  is  that  the  n-mechanism  rnemodoiogy  will  in  general 
provide  us  with  mechanisms  in  which  mere  is  eimer  no  iterative  slack  or  in  which  it 
has  been  minimized.  In  applying  the  rnemodoiogy  we  must  be  aware  of  conditions  mat 
may  suggest  tne  preference  for  a  non-iterative  11-mecnanism. 

The  reader  is  left  to  draw  his/her  own  conclusions  about  companson  wim  Knum  s 
two  implementations,  in  our  implementations  we  nave  chosen  to  separate  me  tasks  of 
insertion  and  search.  We  have  also  taken  precautions  to  handle  the  insertion  of  tne 
first  element  in  the  tree.  As  a  fundamental  principle  of  loop  construction  we  would 
suggest  tnat  any  steptsJ  that  are  only  applied  at  the  last  iteration  should  be  separated 
from  tne  body  of  the  loop.  We  referred  to  mis  principle  earlier  as  me  law  of  separation 
of  concerns. 

Before  leaving  the  tree  search  problem  it  is  worm  noting  mat  the  weakest  iterative 
mechanism  did  not  completely  mislead  us  in  pointing  towards  me  'best*  solution  if  we 
are  prepared  to  resort  to  sentinels  (as  Wirth  does  in  ref.  f  76  J  p  20}).  What  Wirtn  sug¬ 
gests  IS  essentially 

s  7  .key  x:  (sentinel) 
while  tt.key  ^  X  do 

if  X  <  tt.key  — » I  :=  tt.left 
0  X  >.  tt.key  — ♦  t  :=  tt. right 
fl 

This  mechanism  requires  all  leaf  nodes  to  be  linked  to  a  common  node  where  tne 
sentinel  gets  placed  before  the  commencement  of  tne  search. 

if  one  is  to  resort  to  these  tactics  we  would  suggest  tne  following  alternative 
implementation  which  is  based  on  the  application  of  the  weakest  iterative  mechanism 
tnat  could  establish  the  postcondition  (we  have  kept  wim  Knum's  representation). 

a(s] x;  (sentinel) 

Ido  all]  #  X  — > 


rp  p  i;  I  :=  rlil  pr  — »  a(i]  >.  x; 
li;  do  a[i]  >  x  — >  p  :=  i;  i  ;*  p(i]  od 

lod 


This  impiementation  will  on  average  make  less  applications  of  the  test  ‘a(i]  #  x'  man 
Wirth 's  implementation. 


Example  5.11  Maximum  Finding 

We  will  now  make  one  final  diversion  before  moving  on  to  issues  related  to  the 
Classification  of  loop  mechanisms. 

The  problem  we  wish  to  consider  is  that  of  finding  the  maximum  in  an  array  of  ne 
integers.  This  problem  once  again  addresses  the  issues  raised  by  the  tree  searching 
example.  We  will  develop  the  solution  informally  as  even  the  more  formal  development 
is  very  straightforward.  There  are  two  variables  associated  with  the  problem  which  can 
be  changed:  they  are  the  array  index  i.  and  the  maximum  variable  max.  The  weakest 
Iterative  mechanism  which  can  establish  the  postcondition  will  be  one  that  merely  con¬ 
firms  (by  changing  *i*)  that  a  given  candidate  for  the  maximum  is  indeed  the  maximum 
in  the  array.  Our  ii-mechanism  can  therefore  take  the  form 

max.i.n  adl.l.nb: 
do  I  <  n  — > 

if  ati+1]  s  max  — >  I  ;=  i+l 
Q  afi+lj  >  max  — ♦  n  ;=  i 
fi 

od 

Clearly  the  iT-mechanism  as  it  stands  cannot  solve  the  general  problem.  Accommo¬ 
dating  this  fact  we  are  led  to  the  final  implementation  that  selects,  and  then  tries  to 
confirm,  successively  better  candidates  (or  the  maximum  in  the  set 

ip  b  <  nb  — > 

$vri,max,n:integer  — > 

I  ;=  e 

Sdo  i  <  ne  — > 

max,i,n  :=  a(i+l].i+l,ne; 

do  I  <  n  — > 

if  ati+11  s  max  — >  i  :=  i+1 
0  a£i+lj  >  max  — >  n  :=  i 
n 

00 

*00: 

Sr:  i  =  ne  max 
P» 

Like  in  our  previous  example,  we  note  that  the  guards  for  the  outer  loop  and  me  n- 
mecnanism  are  essentially  the  same.  Furthermore  we  see  that  the  n-mechanism  itself 
embodies  a  solution  to  the  general  problem  is  we  include  the  step  that  takes  full 
advantage  of  the  condition  ali+l]  >  max.  With  these  observations  we  are  led  to  me 
alternative  solution  whose  central  mechanism  has  tne  form: 

I.  max  ;=  1,  adl; 
do  I  <  n  — > 

if  aII+1)  s  max  — » i  :=  i+1 

0  a(i+11  >  max  — >  l.max  :*  i+1.  a(i+1l 

fi 

Od 

As  for  our  previous  example,  we  see  mat  this  mechanism  is  iteratively  tight  and  so  is  to 
be  preferred  over  our  original  solution. 


Once  again,  if  we  choose  to  resort  to  tne  use  of  sentinels  we  can  arrive  at  me 
implementation  given  below  which  can  exploit  me  Fi-mechanism. 

i  :=  b; 

00  i  <  n  — > 

i.max.a[n+l]  :=  i+1,  a[i+1],  aU-t-ll: 

do  ali+l]  <  max  — >  i  :=  i+i  od 
od 

Knum  has  shown  (17  1  that  the  maximum  only  gets  updated  on  average  Odog  n) 
times,  consequently  wim  this  implementation  the  guard  *i  <  n*  is  only  tested  on  aver¬ 
age  Odog  n)  ramer  man  n  times  as  in  our  two  previous  algorithms.  Doing  a  statement 
count  with  the  Berkeley  Pascal  compiler  for  n  =  1000  we  find  that  for  random  data  on 
average  3010  statements  are  executed  for  me  second  implementation  while  the  third 
implementation  only  executes  2023  statements. 

From  the  last  two  examples  we  have  considered  it  should  not  be  inferred  that  we  are 
advocating  the  use  of  sentinels.  Mfhat  did  come  as  a  surprise  from  this  investigation 
was  that  application  of  the  IT-mechanism  methodology  in  a  straightforward  way  led  to  a 
solution  to  the  problem  of  finding  the  maximum  that  the  author  had  not  previously  con¬ 
templated.  Others,  unaware  of  the  memodology.  have  also  been  at  a  loss  to  discover 
a  more  efficient  implementation  than  the  conventional  one. 

6.  On  the  Characterization  of  Loop  Mechanisms 

What  is  apparent  from  our  study  of  loops  is  that  there  appears  to  exist  a  set  of 
basic  control  mechanisms  that  can  be  widely  used  to  solve  problems  that  require 
Iterative  solution. 

Rather  than  leave  our  discussion  of  loop  mechanisms  in  its  present  state,  it  would 
seem  appropriate  to  examine  the  prospect  of  formalizing  this  knowledge  in  some  sys¬ 
tematic  manner. 

What  our  investigation  has  done  has  been  to  indicate  that  there  is  possibly  a 
deeper  structure  associated  with  loops  that  we  have  hitherto  not  seriously  exploited. 

in  attempting  to  come  to  terms  with  this  hypothesized  deeper  structure  it  would 
seem  prudent  to  be  aware  of  Chomsky's  seminel  work  in  linguistics  (  18.19  1.  What 
Chomsky  has  been  able  to  do  is  provide  a  framework  for  the  construction  of  theories  of 
language.  Within  this  framework  his  most  important  contribution  has  involved  the 
specification  of  rules  underlying  the  construction  of  sentences  [  18  1  using  phrase 
structure  and  transformational  grammars.  The  relevance  of  Chomsky's  work  in  partic¬ 
ular  and  formal  language  theory  in  general,  has  long  been  recognized  in  computing  in 
the  theory  of  compiler  construction  (  20  ].  We  do  not.  however,  find  the  application  of 
principles  at  least  similar  in  intent  to  Chomsky's  in  programming  methodology.  If  it  is 
possible  to  accomplish  such  a  task  then  one  might  hope  for  a  somewhat  similar  set  of 
benefits  to  those  derived  from  having  a  grammatical  theory  for  the  construction  of 
natural  language. 

The  simplest  and  perhaps  most  obvious  benefit  from  specifically  identifying  a 
higher  level  syntactic  framework  would  be  a  taxonometric  one.  This  would  assist  the 
systematic  study  of  the  discipline.  We  might  also  expect  that  an  awareness  of  such  a 
higher  level  framework  should  aid  the  semahtic  analysis  of  programs.  Explicit 
knowledge  of  these  rules  should  also  improve  a  programmer  s  'competence*  (in 
Chomsky's  sense)  since  initially,  at  least,  (because  programming  does  not  involve  a 
natural  language),  he  or  she  does  not  have  any  'internalized*  rules  for  program  con¬ 
struction  of  the  type  that  Chomsky  claims  that  natural  language  speakers  possess. 


To  anempt  to  do  justice  to  a  grammatical  theory  of  program  construction  is 
beyond  the  scope  and  intent  of  the  present  discussion.  Only  a  brief  outline  and 
exploratory  investigation  of  the  possibillbes  that  we  nave  raised  will  therefore  be  made 
at  this  point 

In  attempbng  to  draw  on  parallels  with  results  in  another  discipline  there  is  always  the 
danger  of  introducing  structure  and  terminology  that  is  of  questionable  relevance.  We 
will  start  this  discussion  by  considering  the  simplest  problem,  that  of  inventing  a  clas¬ 
sification  discipline  for  simple  and  complex  loop  structures. 


6.1.  Classification  of  Loop  Structures 

There  are  many  schemes  that  could  be  selected  to  classify  loops.  We  nave 
Chosen  a  very  simple  scheme  that  will  place  loop  mechanisms  into  a  relatively  small 
number  of  broad  categories  (this  scheme  is  derived  from,  but  independent  of,  the 
more  detailed  phrase  structure  scheme  to  be  described  in  the  next  section).  There 
are  two  categories  of  loops,  s/mp/e  (denoted  either  by  d  or  a )  and  complex  (denoted 
by  A  ori;).  A  simple  loop  mechanism  consists  of  a  single  loop  whereas  a  complex 
loop  refers  to  a  nested  loop  structure.  A  ‘s‘  is  used  to  indicate  a  loop  mechanism;  the 
sub/ecfive  variables  (i.e.  the  required  ‘output*)  of  the  loop  are  conditionally  (or  deduc¬ 
tively)  derived  by  the  loop  mechanism  (e.g.  a  loop  for  finding  the  maximum  in  an 
array).  A  *a*  is  used  for  loops  that  derive  their  results  ihdutnively  (e.g.  a  loop  for  sum¬ 
ming  the  elements  in  an  array).  A  *A"  is  used  for  a  nested  loop  that  condit- 


scripted  indicates  the  presence  of  a  post  termination  state.  A  simple  ciassificauon 
scneme  with  attached  description  alphabets  might  take  the  following  form. 


end  loop 


subscript 
description 
(z,q,i,d,6,f) 
(A,  Z,  6,  a) 


post  termination 
(') 


Basic 

Classification 
(A,  Z,  6,  a) 


By  convention,  if  the  loop  body  refers  to  a  simple  loop,  then  the  roie  of  the  subscripts 
IS  to  describe  how  the  subjective  eiement(s)  in  the  loop  body  are  derived  (note  van- 
abies  used  to  force  termination  are  not  considered). 

The  conventions  used  are  shown  in  the  following  table: 

Descriptor  Derivation 


static 

inductive 

deductive 

functional 


The  descriptive  power  is  increasing  (i.e.  f  has  highest  preference). 

For  complex  loops  the  loop  body  is  considered  to  have  an  initialization  com¬ 
ponent,  a  simple  or  complex  loop,  and  a  possible  post  termination  mechanism.  The 
initialization  component  which  forms  the  left-most  component  of  the  subscript  follows 
the  initialization  conventions  identified  in  section  5  and  empioys  the  descriptors  in  me 
table  above  (allowing  also  for  iterative  initialization).  The  internal  loop(s)  is  described 
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using  the  Dasic  loop  classification  scheme  with  the  convention  that  suDscripts  are 
oroppeo  to  maintain  just  a  two  level  scheme. 

These  simple  conventions  are  sufficient  to  classify  most  (but  not  all)  simple  loop 
mechanisms.  Using  these  conventions  the  classifications  for  some  of  the  examples 
oiscusseo  in  this  paper  are: 

Algorithm  Classifioation 

integer  Square  Root 
Quotient  Remainder 
Binary  Search 
Linear  Search 
Searching  a  two-dim.  array 
inventory  Report 
Prime  Factorization 
Partitioning  an  Array 
Text  Formatting 
Greatest  Common  Divisor 
Two  way  Merge 

It  IS  apparent  that  the  description  provided  by  the  cohvehtions  that  we  have 
adopted  in  this  section  can  only  loosely  classify  loop  mechanisms.  We  must  therefore 
turn  to  the  invention  of  a  device,  whose  role  is  somewhat  akin  to  Chomsky's  phrase 
structure  grammar  (  18  1  in  order  to  more  accurately  characterize  the  structure  of  loop 
mechahisms. 

6.2.  A  Loop  Grammar 

The  intern  in  proposing  a  loop  grammar  is  to  attempt  to  identify  a  higher  level 
underlying  syntactic  structure  that  could  be  employed  in  the  construction  of  loops. 
There  are  possibly  mahy  ways  to  invent  such  a  grammar.  We  will  employ  a  scheme 
that  follows  Oh  fairly  naturally  from  the  conventions  followed  in  the  preceding  section. 

As  a  simple  example  of  a  possible  loop  grammar  we  may  propose  the  following 
rewrite  rules. 

L  — *  P  +  S 

P  — >  ta)  +  (z)  +  (i)  +  (d)  +  (0 
8  — >6  ♦  (R) 

6  ->  (P)+(8) 


a. 

1 


0  . 
1 


z6 

A.  r 
16 


fo* 


d6 


f6' 


66 

A* 


66 


R— >  (z)  +  (i)  +  (d)  +  (f> 
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The  initial  loop  structure  is  L,  S  is  the  accompanying  loop  Dody.  P  refers  to  the 
initialization  segment  and  R  to  the  post-termination  segment.  The  ‘a‘  is  used  to  deal 
with  auxiliary  variables.  The  other  components  identified  in  the  rewrite  rules  have 
been  previously  defined.  Constituent  analysis  of  the  loop  structure  is  performed  textu- 
aily  fop-to-botiom. 

The  terminal  strings  are  the  variables  identified  in  the  loop  mechanism.  Some  exam¬ 
ples  of  applying  this  simple  grammar  are  as  follows  (we  have  used  examples  previ¬ 
ously  discussed  in  the  text)>  it  should  be  noted  that  the  rewrite  rules  we  have  pro¬ 
posed  constitute  only  a  wea/t  grammar  in  that  they  do  not  necessarily  exclude 
incorrectly  formulated  loop  mechanisms. 


Linear  Search  -  Example  A 


(i/ 


Binary  Search  -  Example 


(i) 


6;  'R 

\ 

(n)  a'  d  d 

I  I  I 

(m)  {i,  n)  (found) 


TwO' dimensional  Search  -  Example  c 
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Inventory  Report  Example  D 


(true) 


z  6 ' 

(n)  (j,T)  (g[j],T) 

z  i 

I  I 

(n)  (j,T) 

These  examples  should  be  sufficient  to  indicate  how  a  loop  grammar  might  be  applied. 
Of  course  a  much  more  extensive  study  would  be  needed  to  implement  a  loop  gram¬ 
mar  of  sufficient  power  to  be  of  real  practical  value. 

At  this  point  our  analysis  of  ioop  structures  is  still  not  complete  as  we  nave  yet  to 
identify  useful  transformations. 

6.3.  Loop  Transformations 

What  IS  apparent  from  any  extensive  and  detailed  study  of  loop  mechanisms  is 
that  a  small  number  of  generic  loop  structures  account  for  a  large  number  of  prob¬ 
lems.  This  observation  is  not  necessarily  apparent  from  a  casual  survey  of  the  litera¬ 
ture  but  rather  it  is  a  suggestion  of  what  could  be  achieved  by  application  of  principles 
like  the  law  of  separation  of  concerns  and  other  aspects  of  a  good  discipline  for  loop 
construction. 

Within  the  framework  of  basic  loop  structures  we  find  that  there  are  two  mechan¬ 
isms  that  dominate.  The  simpler  mechanism  is  one  that  maintains  its  loop  invariant 
either  conditionally  or  unconditionally  throughout  its  iterative  phase  by  application  of 
what  IS  essentially  a  single  mechanism  within  the  loop  body. 

The  other  dominant  mechanism  is  one  in  which  there  are  essentially  two  com¬ 
ponents  to  the  loop  body,  one  component  that  maintains  the  loop  invariant  in  a  rela¬ 
tively  straightforward  way  (much  like  the  simpler  mechanism)  and  a  second  often  more 
complex  component  that  needs  to  be  applied  when  the  simpler  component  is  unable  to 
maintain  the  loop  invariant.  This  second  component  also  has  the  role  of  maintaining 
the  loop  invariant  but  it  must  do  so  by  application  of  a  more  complex  (or  at  least  dif¬ 
ferent)  mechanism.  We  will  now  explore  several  useful  transformations  that  can  oe 
used  to  arrive  at  different  implementations  of  these  basic  loop  mechanisms. 

Consider  first  the  basic  loop  mechanism: 

do  B1  — > 
if  Cl  — >S1 

aC2— >S2  ..(6.1) 

fi 

00 

Where  the  condition  C2  is  usually  weaker  than  7C1.  If  it  is  appropriate  to  apply  Cl 
directly  as  a  guard  we  could  increase  the  iterative  strength  of  this  component  by  turn¬ 
ing  It  into  a  loop  thereby  removing  the  need  to  guard  S2  within  the  body  of  the  loop. 
The  transformation  yields 


PS 


Ki’ 

S 
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00  B1  — > 

S2; 

$j:  do  Cl  — >  SI  00  ..(6.2) 

00 

This  transformorion  taKes  up  some  of  the  iterative  slack  in  the  original  mechanism,  it 
can  oe  appropriately  applied  to  problems  like  Fermat's  Factoring  algorithm  [  12  J,  and 
the  prime  factorization  algorithm  where  the  mechanism  SI  needs  to  (or  may  need  to) 
be  applied  on  average  considerably  more  times  tnan  S2  to  complete  the  computation. 
We  will  illustrate  the  transformation  for  the  gcd  algorithm. 

Original  Algorithm 

do  a  ^  b  — > 

if  a  >  b  — >  a  :=  a  -  D 
a  a  <  b  — >  :=  b  -  a 
fi 

00 

Transformed  Implementation 

00  a  ^  b  — > 
b  b  -  a 

»i:  do  a  >  b  — >  a  :=  a  -  b  od 
00 

We  call  this  an  asymmetrical  transformation. 

For  problems  like  the  gcd  algorithm  even  the  transformed  implementation  still 
possesses  some  iterative  slack  because  the  S2  mechanism  may  not  be  iteratively 
strong  enough  to  bring  the  computation  into  a  state  where  it  is  most  appropriate  to 
apply  the  internal  loop.  This  can  be  overcome  by  increasing  the  iterative  strength  of 
ooth  alternative  constructs  in  the  original  algorithm  -  this  amounts  to  a  symmetric 
transformation.  This  second  transformation  is  given  below. 

Symmetric  Transformation 
do  B1  — > 

rp  SI  pr  — >  Cl  V  IB1;..(6.3) 

$i:  do  Cl  — >  S2  od 
od 

Applying  this  transformation  to  the  original  gcd  algorithm  we  get 
do  a  ^  b  — > 

rp  b  :=  b  -  a  pr  — >  0  1  a; 

»i:  do  a  >  b  — » a  ;=  a  -  b  od 
Od 

This  implementation  is  iteratively  tight.  As  we  have  seen  in  our  discussion  of  a  tree- 
searching  algorithm  it  is  not  always  appropriate  to  make  such  transformations  -  i.e. 
when  the  original  mechanism  is  already  iteratively  tight.  It  is  important  to  recognize 
that  these  transformations  are  reversible.  Our  constructive  methodology  will  yield  loop 
bodies  with  the  greatest  iterative  strength  (i.e.  mechanisms  that  are  iteratively 
resolved),  if  circumstances  demand,  such  solutions  can  be  transformed  to  an  imple¬ 
mentation  more  appropriate  for  the  problem. 
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When  the  conditions  Cl  and  C2  in  (6.1)  are  not  appropriate  tor  use  as  guaros 
then  the  transformations  become  siightiy  more  compiex  than  (6.2)  and  (6.3)  aithougn 
they  may  be  thought  to  form  analogs  of  (6.2)  and  (6.3)  respectively. 

The  simplest  of  the  cases,  which  is  often  encountered  in  file  processing,  has  the 
foiiowing  iteratively  resolved  representation: 

PI; 

do  Bl  — > 

P2;  F2; 

do  B2  — > 

i(C2— >S2  ..(6.4) 

0 1C2 ->  F2' 
fi 

od; 

R2 

od 

Note  that  in  this  simplest  representation  P2  is  an  inductive  initialization  for  the  internal 
loop,  the  guards  Bl.  and  B2  are  equivalent,  and  F2  and  F2'  are  the  elements  of  tne 
mecnanism  needed  to  force  termination  of  the  internal  loop.  The  inventory  report 
prooiem  is  an  example  of  a  mechanism  that  possesses  this  basic  underlying  loop 
structure.  The  corresponding  iteratively  unresolved  mechanism  has  the  following 
form: 

PI;  P2; 

do  Bl  — > 
if  C2  — >  S2 

0  1C2  — >  R2;  P2  ..(6.5) 
fi 

Od; 

R2 

Rewriting  the  inventory  report  implementation  in  this  form  we  have: 

/  :=  «; 

j.  T:=  j+l,t(j+1]; 

00j<  no  — > 

if  g[jl  =  g(j+ll  — >  j.  T  :=  j+1.  T  ♦  tQ+11 

Q  g[J]  ^  gCj+11  — ♦  write  (gljl.  T);  j.  T  :=  j+1.  ttj+ll 

fi 

Od; 

write  (g[|l.  T) 

The  mechanism  (6.5)  reverts  to  a  simpler  form  when  there  is  no  post-termination 
mecnanism  R2  for  the  internal  loop.  The  iteratively  resolved  maximum  finding  algo¬ 
rithm  has  these  underlying  characteristics.  Its  corresponding  iteratively  unresolved 
mechanism  has  the  form: 

PI;  P2 

do  Bl  — + 
if  C2  — >  S2 

0?C2— >P2  ..(6.6) 

fi 


00 


The  underlying  reason  for  the  difference  between  (6.5)  and  (6.6)  is  that  in  (6.6)  the  ini¬ 
tialization  P2  is  capable  of  establishing  the  post-condition  whereas  in  (6.5)  tne 
corresponding  P2  is  not  capable  alone  of  establishing  the  post-condition  i.e.  P2  fol¬ 
lowed  by  R2  is  needed  to  establish  the  postcondition.  Such  distinctions  as  that 
between  6.5  and  6.6  indicate  the  value  of  loop  transformations. 

It  should  be  pointed  out  that  Bergiand  gi^s  an  implementation  of  the  inventory 
report  problem  [11]  which  seemingly  avoids  the  need  for  a  post-termination  mechan¬ 
ism.  This  nappens  only  because  he  employs  wnat  is  effectively  a  sentinel  and  so  his 
solution  IS  not  really  a  general  solution  for  the  problem. 

When  tne  dynamic  initialization  for  the  internal  loop  mechanism  has  a  deductive 
component  tne  iteratively  resolved  form  is: 

PI; 

do  ai  — > 

D2;  S2;  F2 

do  VB2  — > 
if  C2  — >  S2 

Q  7C2  F2'  ..(6.7) 

fi 

00 

Od 

and  the  unresolved  form  is: 

PI; 

do  B1  — > 
if  C2  —>  82 

0  IC2  — >  02:  82  ..(6.8) 

fi 

od 

There  may  also  be  a  02  component  after  termination.  If  there  is  more  man  one 
internal  loop  in  sequence  then  the  transformations  are  slightly  more  complex. 

We  have  now  covered  most  of  the  asymmetric  transformations.  The  symmetric 
analog  of  6.3  is  needed  where  it  is  not  appropriate  to  use  Cl  as  a  guard. 

The  iteratively  resolved  symmetric  transformation  has  the  form: 

PI;  F2; 
do  B1  — > 
rp 

if  C2  — >  82 
0 IC2  — >  F2 
fi 

pr-^7B2;  ..(6.9) 

$i:  do  B2'  — > 

if  1C2  — >  82' 
a  C2  — >  F2' 
fi 

Od 

Od 

R1 


The  unresolved  symmetric  form  is: 
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PI; 

00  B2  A  B2'  — > 
if  C2  ->  S2 

0  7C2— >S2'  ..(6.10) 

fi 

00 : 

R1 

The  two-way  merge  is  a  gooO  example  that  exhibits  both  these  forms. 

We  have  now  covereo  transformations  for  most  of  the  simple  cases  mat  we  nave 
expioreo  in  this  paper.  The  ioop  Oesigner  shouiO  be  familiar  wim  all  these  forms  ano 
have  an  unoerstanoing  of  when  it  is  appropriate  lano  when  it  is  not)  to  mtroouce 
forceo  termination  ano  iteratively  resolved  mechanisms. 

In  concluding  our  discussion  of  ioop  transformations  several  things  are  apparent. 
Firstly,  this  subject  deserves  a  deeper  and  more  extensive  treatment  than  nas  been 
given  here  as  a  fully  developed  theory  of  loop  transformations  would  put  programming 
methodology  on  a  much  sounder  footing.  Such  a  study  would,  hopefully,  shed  more 
light  on  the  connection  between  the  syntactic  structure  of  loop  mechanisms  and  their 
underlying  semantics.  Even  the  present  treatment  can  tell  us  such  things  as  that  tne 
post-termination  mechanism  of  an  internal  loop  holds  the  key  to  me  purpose  of  tne 
enclosing  external  loop.  Also  where  there  is  a  IT-mechanism  and  no  post-termination 
state  in  the  loop  body  then  we  can  usually  work  out  from  the  n-mechanism  alone  wnat 
is  the  purpose  of  the  loop  mechanism  -  me  fT-mechanism  for  the  partitioning  aigo- 
rimm  illustrates  this  point  rather  well.  Pursuing  such  a  course  we  are  inevitably  con¬ 
fronted  wim  me  question  ‘should  we  search  for  deep  structures  of  loop  mechanisms 
along  the  lines  of  that  pursued  and  disputed  by  linguists  in  their  study  of  natural 
language?' 

7.  Conclusions 

Jackson's  data  structure  design.  Oifkstra's  rnemodoiogy.  or  any  other  mernodoi- 
ogy.  including  the  present  one  is  only  useful  so  long  as  one  applies  it  not  as  a  beli¬ 
ever.  but  as  a  rational  critic.  Floyd.  Hoare.  Oljkstra,  Wirm.  Jackson.  Qries  and  others 
who  have  laid  the  foundations  of  much  of  what  is  current  programming  would,  i  am 
sure,  be  the  first  to  agree  with  this  assertion.  Methodologies,  by  their  very  nature,  are 
always  developed  within  a  limited  context  and  with  limited  experience  ano  so  we  must 
always  be  wary  about  their  mechanical  application. 

Much  of  what  we  have  discussed  in  this  paper  is  concerned  with  program  quality. 
Unfortunately,  quality  in  any  creative  enterprise  usually  has  the  definition  of  being  mat 
which  is  always  produced  by  the  creator.  The  reader  must  make  his  or  ner  own  judge¬ 
ments  as  to  whemer  we  have  also  fallen  into  this  trap.  Our  over-riding  intent  has  been 
to  explore  me  use  of  tools  that  may  be  helpful,  both  in  improving  the  quality  of  tne 
design  process  and  of  the  designed  product,  in  attempting  to  develop  an  effective 
design  process  we  nave  sought  well-defined  composition  rules  that  can  partition  bom 
tne  design  process  itself,  and  also  me  finished  product.  Our  measures  of  quality  in 
me  finished  product  have  been  semantic  clarity,  generality,  and  mechanistic  (as  dis¬ 
tinct  from  textual)  simplicity.  Our  proposals  relating  to  the  characterization  of  loops 
nave  been  somewhat  more  exploratory.  However,  they  may  provide  a  framework  in 
Which  an  intelligent  and  consistent  discussion  of  program  quality  could  take  place. 


HJ I  I M  n  M.':  ^  '*.1 
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